[
https://issues.apache.org/jira/browse/CAMEL-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf Batt updated CAMEL-10123:
--------------------------------
Priority: Minor (was: Major)
> gzip added to Accept-Encoding although not requested
> ----------------------------------------------------
>
> Key: CAMEL-10123
> URL: https://issues.apache.org/jira/browse/CAMEL-10123
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
> Affects Versions: 2.17.1
> Reporter: Rudolf Batt
> Priority: Minor
>
> I have a standard proxy route using the camel-jetty component:
> {code}
> <route>
> <from uri="jetty:http://0.0.0.0:8082/docs?matchOnUriPrefix=true"/>
> <to
> uri="jetty:http://127.0.0.1:8080/docs?bridgeEndpoint=true&throwExceptionOnFailure=false";
> />
> <route>
> {code}
> The Problem is this: If a request is send to the proxy (8082) with the HTTP
> header "Accept-Encoding: deflate" {code}curl -s -v -H 'Accept-Encoding:
> deflate' 'http://localhost:8082/docs/setup.html' -o /dev/null{code} the
> "backend server" receives a request with the header "Accept-Encoding:
> gzip,deflate".
> This would be OK, if the compression is "terminated" at the communication to
> the client. However if the "backend server" returns gzipped content (marking
> it with the response header "Content-Encoding: gzip"), the proxy returns that
> header as well, although no compression is done:
> I can see that, because I get a "Exception: Not in GZIP format" in my Java
> Client. Also comparing the downloaded size with my curl command
> ({code}--write-out 'size_download=%{size_download}\n'{code}) reveals the
> fact, that the response is not compressed.
> (I'll post my workaround, as soon as I found it. I guess I have to use a
> GZipHandler..)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
