RE: Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-06-06 Thread Primož Kokol
Hi Ramesh, Please take a look at the example I've attached. After running it (mvn clean install exec:java) server will be started on port 8080 and reverse proxy on port . You will be able to access the server on 8080 but you will have to provide credentials (test/test) when accessing

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-05-14 Thread Ramesh
Arjohn Kampman-2 wrote We've updated from restlet 2.1.4 to 2.2.0 now and to our surprise this fixed the Redirector problems. In fact, Redirector works perfectly out-of-the-box, including the digest authentication. No subclassing required. So probably this was a bug in 2.1.4 that has been

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-05-06 Thread Thierry Boileau
Hello all, I'm having a look at it. Best regards, Thierry Boileau 2014-05-01 12:27 GMT+02:00 Arjohn Kampman arjohn.kamp...@vound-software.com : Any thoughts on the encoding related bug in Redirector? --

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-05-01 Thread Arjohn Kampman
Any thoughts on the encoding related bug in Redirector? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3077354

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-25 Thread Arjohn Kampman
Hi Jerome, Before moving to 2.2.0 I first tried 2.1.7, but that has the same issue. We do run into a new issue with the Redirector in 2.2.0 now though. The problem appears related to entity encoding. Responses that are encoded by the back-end server aren't properly delivered by the proxy to

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-25 Thread Arjohn Kampman
Hi Jerome, others, We've figured out what is going wrong by monitoring the traffic with Wireshark. The problem is indeed, as suspected, related to gzip encoding. I'll try to explain with one of the traces that we've captured: 1. Client sends a request to the proxy with Accept-Encoding: gzip.

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-25 Thread Tim Peierls
Could this be addressed by turning off the DecoderService? There's no need to perform the decompression in the first place, is there? On Fri, Apr 25, 2014 at 8:13 AM, Arjohn Kampman arjohn.kamp...@vound-software.com wrote: Hi Jerome, others, We've figured out what is going wrong by

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-25 Thread Arjohn Kampman
For whatsoever reason, disabling the decoder service results in a NPE being thrown at org.restlet.routing.Redirector.outboundServerRedirect(Redirector.java:349). That's this line in 2.2.0: next = getContext().getClientDispatcher(); AFAICT, this can only happen if the context is

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-24 Thread Jerome Louvel
Thanks for the feed-back Arjohn! We have completely replaced the internal HTTP connector in 2.2 so that certainly helped a lot. I don't think 2.1.7 would solve your issue but that could be interesting to confirm. Best, Jérôme On Tue, Apr 22, 2014 at 1:45 AM, Arjohn Kampman

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-22 Thread Arjohn Kampman
We've updated from restlet 2.1.4 to 2.2.0 now and to our surprise this fixed the Redirector problems. In fact, Redirector works perfectly out-of-the-box, including the digest authentication. No subclassing required. So probably this was a bug in 2.1.4 that has been fixed somewhere in the 2.2

RE: Re: Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-18 Thread Primož Kokol
Hi again, My next try was to remove all original headers (like default implementation do) and then preserver only Authentication header. So I replaced this line: https://github.com/restlet/restlet-framework-java/blob/2.2/modules/org.restlet/src/org/restlet/routing/Redirector.java#L407 with

Re: Re: Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-18 Thread Tim Peierls
I don't have time to look at this, unfortunately. I have Basic auth working with outbound redirection. I *don't *change the way the headers are removed, but I do remove the challenge response. // From my Redirector subclass: @Override protected void outboundServerRedirect(

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-18 Thread Arjohn Kampman
I've debugged the problem to an infinite loop when trying to set the Via header on the request that the proxy sends to the back-end server. This infinite loop is not triggered when Redirector removes the headers becuase HttpInboundRequest.getRecipientsInfo() has a getHeaders() != null check.

Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-17 Thread Tim Peierls
The code that does the header removal is here: https://github.com/restlet/restlet-framework-java/blob/2.2/modules/org.restlet/src/org/restlet/routing/Redirector.java#L405-L413 If you're confident that that's what you want, you can extend Redirector and override serverRedirect to do everything it

RE: Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-17 Thread Primož Kokol
Tim, thanks for advice. That is actually one of the first things I've tried. After extending Redirector and overriding serverRedirect method so that line which clears the headers was removed 1002 Internal Connector Error was always returned as response (from proxy) so I thought this was not

Re: Re: Transparent reverse proxying using org.restlet.routing.Redirector

2014-04-17 Thread Tim Peierls
I'm guessing you have to very selective about which headers you allow to remain. On Thu, Apr 17, 2014 at 3:08 PM, Primož Kokol primoz.ko...@gmail.comwrote: Tim, thanks for advice. That is actually one of the first things I've tried. After extending Redirector and overriding serverRedirect