[
https://issues.apache.org/jira/browse/HTTPCLIENT-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047531#comment-18047531
]
Stephane Nicoll commented on HTTPCLIENT-2409:
---------------------------------------------
> [~snicoll] They can if they want. There are also users who want both
> automatically decompressed entities and details about the original response
> message, likely to find out if the message was compressed in the first place.
If by "if they want" you mean disabling unzipping, that's not helpful at all.
If they are using a higher-level abstraction, they do not care. Again, I am not
talking about the perspective of someone using HttpClient directly in their own
code: they can upgrade, follow the release notes and adapt. That's not the same
thing for someone building an abstraction over the client and having to handle
more than one version on top of that.
> The point is one can can get the old behavior back at any time with just a
> few simple lines of code.
I think this conversation is going in circles. My point is that they don't care
about the old vs. new behavior to begin with. However, I do believe that having
the headers advertizing the content is gzipped and then the inpustream isn't is
really strange. I understand that folks would like the headers unmodified: that
doesn't mean we have to be in this half-consistent state.
>From my perspective; it's either headers unchanged and inputstream as it i is.
>If you want to keep the automatic handling of the compression, then the
>unaltered headers should be available with some other means. If you insist on
>making the inputstream handling the compression transparently, what we have
>now is worse, IMO.
> 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]
