Yavor Stankov created HTTPCLIENT-2376:
-----------------------------------------

             Summary: The Accept-Encoding value has changed after update to 
Apache HTTP Client 5.5
                 Key: HTTPCLIENT-2376
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2376
             Project: HttpComponents HttpClient
          Issue Type: Bug
          Components: HttpClient (classic)
    Affects Versions: 5.5
            Reporter: Yavor Stankov


I just saw that the requests sent by the HTTP Client 5.5 has change in the 
Accept-Encoding value from: *gzip, deflate* to: {*}gzip, x-gzip, deflate{*}.

I checked the code and the change is coming from the constructor of the 
*ContentCompressionExec* which now no longer takes in mind the parameter 
{*}acceptEncoding{*}.

 

This constructor is called by the *HttpClientBuilder* which is passing the 
*acceptEncoding* parameter by using the values from the  *contentDecoderMap* 
for which there is a setter in the builder which we use and we rely on having 
exactly these values for the header:

        *LinkedHashMap<String, InputStreamFactory> contentDecoderMap = new 
LinkedHashMap<>();*

        *contentDecoderMap.put("gzip", GZIPInputStreamFactory.getInstance());*

        *contentDecoderMap.put("deflate", 
DeflateInputStreamFactory.getInstance());*

        
*HttpClientBuilder.create().setContentDecoderRegistry(contentDecoderMap)...*

 ** 

I know that x-gzip is a legacy value for gzip and it is most probably added for 
compatibility reasons only and it should not have huge affect, but I'm afraid 
that we are calling a lot of different servers some of which are using other 
HTTP based protocols and I don't really know if this could affect out 
processing.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to