[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-2409.
-------------------------------------------
    Resolution: Invalid

[~cristian.vat] The current behavior of HttpClient is correct. The behavior of 
previous versions was wrong. The response object represents the response 
message as generated by the opposite endpoint. The actual properties of the 
content entity are reflected by its properties and may differ from those of 
original content body sent by the opposite endpoint
{noformat}
HttpEntity#getContentLength
HttpEntity#getContentType
HttpRntity#getContentEncoding
{noformat}
I did make a mistake by not mentioning this behavioral change in the release 
notes. I apologize for that.

If you are absolutely sure that you want the content length header stripped 
from the original response message you can do it with a custom exec interceptor
{code:java}
CloseableHttpClient httpclient = HttpClients.custom()
        .addExecInterceptorAfter(
                ChainElement.COMPRESS.name(),
                "custom",
                (request, scope, chain) -> {
                    ClassicHttpResponse response = chain.proceed(request, 
scope);
                    HttpEntity entity = response.getEntity();
                    if (entity != null && entity.getContentLength() == -1) {
                        response.removeHeaders(HttpHeaders.CONTENT_LENGTH);
                    }
                    return response;
                })
        .build();
{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]

Reply via email to