[
https://issues.apache.org/jira/browse/HTTPCLIENT-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108022#comment-18108022
]
Veit Guna commented on HTTPCLIENT-2409:
---------------------------------------
Sorry for digging up this old ticket.
Last week we exactly ran into this issue in production when upgrading our
httpclient from 5.5.1 to 5.6.2 to address
[https://github.com/advisories/GHSA-hf6x-8p5f-cgmf.]
And yes, we're using Spring Boot and its RestTemplate. We were quite surprised
seeing this suddenly breaking - only some of our customers were using gzip
compressed responses which was not covered by our tons of tests.
Anyway. I just wanted to give some feedback from the outside - without knowing
HttpClient internals.
If the argumentation is, that users should be able to access the origin,
unmodified request, then it's only consistent to provide also the actual
payload unmodified (=compressed) when getting the stream. Only changing one of
them (headers, payload) leads to inconsistencies and would strictly speaking
violate the HTTP spec where Content-Length should reflect the payload length
(or omitted) if Content-Encoding is gzip in a response. So I kind of agree with
the previous view of the ticket creator.
So either keep the headers plus payload as-is or provide auto-decompression
plus removal/changing the headers to comply with the specs. If the origin
headers are really of interest, one could keep them in a separate map for
access or the other way around: keep everything as-is, but provide a
getDecompressedPayload().
But anyway, no offense, just sharing my surprise and thank you for providing
such a library in the first place!
> Content-Length header not removed/modified when decompressing
> -------------------------------------------------------------
>
> Key: HTTPCLIENT-2409
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2409
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 5.6
> Reporter: Cristian Vat
> Priority: Major
>
> When decompressing gzip or other compression schemes the Content-Length
> header is not modified/removed anymore as it was before, this can lead to
> unexpected behaviors like truncation depending on caller behavior.
>
> Originally thought it was a spring issue with RestClient as
> https://github.com/spring-projects/spring-framework/issues/36064
> Summary:
> * Content-Encoding: gzip
> * Content-Length: 9075
> * actual read content if reading fully: 56815
>
> It's a combination of Spring and HttpClient behaviors but it lead to
> truncation at the compressed content length.
> I checked JDK HttpClient and Jetty HttpClient and they remove the
> Content-Length header if doing decompression.
> The same seems to have been the case in HttpComponents HttpClient but then
> the code that removed the headers was removed on 20th October in
> [https://github.com/apache/httpcomponents-client/commit/56122fd33fb8a67d23369a81f6e1d89aabf4ba10]
> ?
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
