[
https://issues.apache.org/jira/browse/CAMEL-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362784#comment-15362784
]
Rudolf Batt commented on CAMEL-10123:
-------------------------------------
Using the "HttpHeaderFilterStrategy" as "headerFilterStrategy" fixes this
behavior.
{code}<bean id="httpHeaderFilter"
class="org.apache.camel.http.common.HttpHeaderFilterStrategy" />{code}
...
{code}<from
uri="jetty:http://0.0.0.0:8082/docs?matchOnUriPrefix=true&headerFilterStrategy=httpHeaderFilter"/>{code}
BTW: The GzipHandler only works, if this headerFilterStrategy is used!
Otherwise it refuses to work due to the "Content-Encoding" header... ^^
Not sure, if this all is expected to work like this. If that is the case, it
should be documented at least.
> 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
>
> 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)
