[
https://issues.apache.org/jira/browse/HTTPCLIENT-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047503#comment-18047503
]
Oleg Kalnichevski edited comment on HTTPCLIENT-2409 at 12/25/25 10:26 AM:
--------------------------------------------------------------------------
> Yes, they are correct. I'd argue that this argument should be applied
> consistently and they should then get an {{InputStream}} that's unaltered.
[~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.
> I am actually working on Spring Framework as well and got [a similar
> report|https://github.com/spring-projects/spring-ws/issues/1754] via the
> Spring Web Services project. You can see the feedback of [someone else on the
> project|https://github.com/spring-projects/spring-framework/issues/36064#issuecomment-3682060777]
> if that helps assessing how this change is perceived.
I am a happy Spring user myself, though I am not a big fan of Spring HTTP
abstraction but this is beyond the point.
The point is one can can get the old behavior back at any time with just a few
simple lines of code.
Oleg
was (Author: olegk):
> Yes, they are correct. I'd argue that this argument should be applied
> consistently and they should then get an {{InputStream}} that's unaltered.
[~snicoll] If they can. 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.
> I am actually working on Spring Framework as well and got [a similar
> report|https://github.com/spring-projects/spring-ws/issues/1754] via the
> Spring Web Services project. You can see the feedback of [someone else on the
> project|https://github.com/spring-projects/spring-framework/issues/36064#issuecomment-3682060777]
> if that helps assessing how this change is perceived.
I am a happy Spring user myself, though I am not a big fan of Spring HTTP
abstraction but this is beyond the point.
The point is one can can get the old behavior back at any time with just a few
simple lines of code.
Oleg
> 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]
