Http proxying double gzip problems:

[greenstar <jn...@gmail.com>]

Here is the scenario:  (The intention is for this endpoint is to proxy
requests)

from("jetty:http://...").to("http://dst...")

However, when a request comes in as follows:

  GET / HTTP/1.1
  Accept-Encoding: gzip, deflate
  ...

This request gets proxied to the destination.  The destination returned a
gzip response (since that was requested):

  HTTP/1.1 200 OK
  Content-Encoding: gzip
  ...

DefaultHttpBinding takes this request and gzips it a second time (since
Exchange.CONTENT_ENCODING is set to gzip).  This double gzipped message is
then returned to the client (which then obviously causes failure).

What is the purpose of the current gzip functionality DefaultHttpBinding? 
This causes problems with proxying.  Thoughts?  Shouldn't gzip be handled as
a processing stage elsewhere in the pipeline if that's desired?





-- 
View this message in context: http://old.nabble.com/Http-proxying-double-gzip-problems%3A-tp28406337p28406337.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Http proxying double gzip problems:

[Willem Jiang <wi...@gmail.com>]

Hi,

I did some bug fix[1][2] on this gzip issue recently.
Now you can setup the proxy like this

from("jetty:http://xxx?bridgeEndpoint=true").to("http://xxx?bridgeEndpoint=true");

Please check out the latest Camel 2.3-SNAPSHOT to verify it.

[1]https://issues.apache.org/activemq/browse/CAMEL-2686
[2]https://issues.apache.org/activemq/browse/CAMEL-2694

Willem

Willem Jiang wrote:
> camel-http supports the gzip content encoding out of box on the 
> HttpConsumer (server side), it just unzip the request message, and pass 
> it into the camel processor, and then zip the response message for 
> returning. I don't think HttpProducer will zip the request message when 
> routing the request to another http server.
> 
> so for you case, need to add the processor to zip the body message for 
> the HttpProducer, or just find a way to disable the gzip function from 
> camel-http component.
> 
> Willem
> 
> greenstar wrote:
>> Here is the scenario:  (The intention is for this endpoint is to proxy
>> requests)
>>
>> from("jetty:http://...").to("http://dst...")
>>
>> However, when a request comes in as follows:
>>
>>   GET / HTTP/1.1
>>   Accept-Encoding: gzip, deflate
>>   ...
>>
>> This request gets proxied to the destination.  The destination returned a
>> gzip response (since that was requested):
>>
>>   HTTP/1.1 200 OK
>>   Content-Encoding: gzip
>>   ...
>>
>> DefaultHttpBinding takes this request and gzips it a second time (since
>> Exchange.CONTENT_ENCODING is set to gzip).  This double gzipped 
>> message is
>> then returned to the client (which then obviously causes failure).
>>
>> What is the purpose of the current gzip functionality 
>> DefaultHttpBinding? This causes problems with proxying.  Thoughts?  
>> Shouldn't gzip be handled as
>> a processing stage elsewhere in the pipeline if that's desired?
>>
>>
>>
>>
>>
> 
> 

Re: Http proxying double gzip problems:

[Willem Jiang <wi...@gmail.com>]

camel-http supports the gzip content encoding out of box on the 
HttpConsumer (server side), it just unzip the request message, and pass 
it into the camel processor, and then zip the response message for 
returning. I don't think HttpProducer will zip the request message when 
routing the request to another http server.

so for you case, need to add the processor to zip the body message for 
the HttpProducer, or just find a way to disable the gzip function from 
camel-http component.

Willem

greenstar wrote:
> Here is the scenario:  (The intention is for this endpoint is to proxy
> requests)
> 
> from("jetty:http://...").to("http://dst...")
> 
> However, when a request comes in as follows:
> 
>   GET / HTTP/1.1
>   Accept-Encoding: gzip, deflate
>   ...
> 
> This request gets proxied to the destination.  The destination returned a
> gzip response (since that was requested):
> 
>   HTTP/1.1 200 OK
>   Content-Encoding: gzip
>   ...
> 
> DefaultHttpBinding takes this request and gzips it a second time (since
> Exchange.CONTENT_ENCODING is set to gzip).  This double gzipped message is
> then returned to the client (which then obviously causes failure).
> 
> What is the purpose of the current gzip functionality DefaultHttpBinding? 
> This causes problems with proxying.  Thoughts?  Shouldn't gzip be handled as
> a processing stage elsewhere in the pipeline if that's desired?
> 
> 
> 
> 
>