On Wed, 2025-06-18 at 12:05 +0000, Stankov. Yavor wrote:
> Hi,
>
> 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 is a bug. Please raise a ticket in JIRA for this defect.
Oleg
>
> 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(contentDecoderMa
> p)...
>
>
>
> 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.
>
> So the question is - is this a bug - since the constructor is not
> deprecated (ContentCompressionExec) but the value is not used anymore
> (acceptEncoding)? Or if not and this will be the behavior in the
> future, what is the best way to override this behavior?
>
> Best Regards,
> Yavor
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
