Thank you David and Federico regarding the duplicate decompression - I
should've found this in the release notes myself..
Another 'duplicate' issue I have is with the Camel REST component,
backed by Felix Jetty12 servlet (in Karaf).
There's two Content-Type headers in the Http Response, as one can see
when tracing the caller side Httpclient:
http-outgoing-0 << "HTTP/1.1 200 OK[\r][\n]"
http-outgoing-0 << "Date: Sat, 05 Sep 2026 18:44:57 GMT[\r][\n]"
http-outgoing-0 << "Content-Type: application/json[\r][\n]"
http-outgoing-0 << "Access-Control-Allow-Headers: Origin, Accept,
X-Requested-With, Content-Type, Access-Control-Request-Method,
Access-Control-Request-Headers[\r][\n]"
http-outgoing-0 << "Access-Control-Allow-Methods: GET, HEAD, POST,
PUT, DELETE, TRACE, OPTIONS, CONNECT, PATCH[\r][\n]"
http-outgoing-0 << "Access-Control-Allow-Origin: *[\r][\n]"
http-outgoing-0 << "Access-Control-Max-Age: 3600[\r][\n]"
http-outgoing-0 << "Content-Type: application/json[\r][\n]"
The first header appearance seems to come from the underlying Jetty
server when constructing the response, but not totally sure.
What comes after the first 3 lines seem to be the headers passed by
Camel down to the Servlet.
My workaround is to filter out the "Content-Length" header with a
HeaderFilterStrategy implementation.
This gets rid of the 2nd header appearance.
What puzzles me slightly is that DefaultHttpBinding.doWriteResponse()
first uses HttpServletResponse.setContentType() and then, the content
type is passed again via addHeader().
Any ideas welcome
- Martin
