Apologies for dredging up an issue that has been apparently been in
published curl versions since at least about a year, but we've only
just encountered it while upgrading a system from Ubuntu 17.10 to
18.04. The relevant commit is
https://github.com/curl/curl/commit/dbcced8e32b50c068ac297106f0502ee200a1ebd#diff-ff9fb98500e598660ec2dcd2d8193aac
if I'm not mistaken.

In curl versions up to at least 7.56.0, setting
CURLOPT_ACCEPT_ENCODING to values other than NULL resulted in curl
decoding "gzip" and "deflate" and quietly passing any other Encoding,
such as "None", which is mistakenly used by one of our customers.
Newer versions of curl return (61) "Unrecognized content encoding
type...". The new behavior is documented in INTERNALS.md (and its
predecessors) since 019c4088cf from April 2003 (with a minor error,
see patch). https://curl.haxx.se/libcurl/c/CURLOPT_ACCEPT_ENCODING.html
on the other hand does not specify how unknown encodings are handled -
I would suggest copying the relevant sentece from INTERNALS.md in
there.

As far as I can see, there are no options or combinations of options
that can be set to restore the old behavior, which, at least for us,
is desirable in that we can handle unknown encodings ourselves, in
most cases by passing the unaltered response to the requestor, or in
the aforementioned case, ignoring "None". Am I overlooking something,
or is there any chance to get the old behavior back in a future
release, e.g. by requiring a specific value for
CURLOPT_ACCEPT_ENCODING, a new option, maybe
CURLOPT_IGNORE_UNKNOWN_CONENT_ENCODING, or possibly a somewhat more
sane method?

Rainer

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html