[
https://issues.apache.org/jira/browse/HTTPCLIENT-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047475#comment-18047475
]
Stephane Nicoll edited comment on HTTPCLIENT-2409 at 12/25/25 6:33 AM:
-----------------------------------------------------------------------
> There are people who would like to have the original message unaltered and
> they are actually correct.
Yes, they are correct. I'd argue that this argument should be applied
consistently and they should then get an {{InputStream}} that's unaltered.
If you take it from the perspective of a (direct) user of this project, then I
guess it's fine as they don't have to deal with the compression since they know
it's done for them. From the perspective of a higher-level API building on top
of this project? Not so much. The standard HTTP way of doing things is checking
the headers, isn't it? Now we have dedicated methods so we need ourselves to do
some indirection to figure out what to do. The users is providing us the client
so we can't start modifying behind their back to add an interceptor.
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.
was (Author: snicoll):
> There are people who would like to have the original message unaltered and
> they are actually correct.
Yes, they are correct. I'd argue that this argument should be applied
consistently and it should be possible to get an {{InputStream}} that's
unaltered. Is that possible?
If you take it from the perspective of a (direct) user of this project, then I
guess it's fine as they don't have to deal with the compression since they know
it's done for them. From the perspective of a higher-level API building on top
of this project? Not so much. The standard HTTP way of doing things is checking
the headers, isn't it? Now we have dedicated methods so we need ourselves to do
some indirection to figure out what to do. The users is providing us the client
so we can't start modifying behind their back to add an interceptor.
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.
> 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]
