You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Stephane Nicoll (Jira)" <ji...@apache.org> on 2025/12/25 06:33:00 UTC
[jira] [Comment Edited] (HTTPCLIENT-2409) Content-Length header not removed/modified when decompressing
[ 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:32 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 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.
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 the 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org