Unsupported content encoding to be treated as an error

[ok2c]

Treat unsupported content encoding as an error. @arturobernalg Please double-check

[arturobernalg]

make sense. LGTM @ok2c

[plesingr-aeb]

Hi, I have a problem with this change.
Using HttpClients.custom() with some adaptions (useSystemProperties, setTargetAuthenticationStrategy, setRoutePlanner(new SystemDefaultRoutePlanner(proxySelector)), I have a simple request like

GET something
Accept: text/plain

w/o specifying any accept-encoding. The client appears to fill in some default codecs in this header before it is sent (it was filled in the previous versions, too).
The response from the server is

Content-Encoding: UTF-8
Content-Type: text/plain
foo bar

It worked with the previous versions but now the request fails with Unsupported Content-Encoding: utf-8. Am I doing something wrong?

[ok2c]

It worked with the previous versions but now the request fails with Unsupported Content-Encoding: utf-8. Am I doing something wrong?

@plesingr-aeb You are doing nothing wrong, but the origin server does. UTF-8 is a charset, not a content encoding. The previous versions of HttpClient ignored such violations. As of 5.6 HttpClient support many different content encodings and the handling logic got stricter.

[plesingr-aeb]

@ok2c Thanks for the explanation (meanwhile, I also got the issue and a solution as well). But what should I do if I have such a legacy issue and can neither fix it nor use a previous client version (because of some internal update policies)?

[ok2c]

@plesingr-aeb One option is to turn off automatic content decompression. A better solution would be to introduce a custom exec interceptor that drops that silly header before the response gets processed by the standard execution pipeline.

[plesingr-aeb]

@ok2c Sounds good, thanks.