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
diff --git a/docs/INTERNALS.md b/docs/INTERNALS.md index ab04fec7e..944f26e06 100644 --- a/docs/INTERNALS.md +++ b/docs/INTERNALS.md @@ -678,7 +678,7 @@ Content Encoding understands how to process responses that use the "deflate", "gzip" and/or "br" content encodings, so the only values for [`CURLOPT_ACCEPT_ENCODING`][5] that will work (besides "identity," which does nothing) are "deflate", - "gzip" and "br". If a response is encoded using the "compress" or methods, + "gzip" and "br". If a response is encoded using "compress" or any other unsupported methods, libcurl will return an error indicating that the response could not be decoded. If <string> is NULL no Accept-Encoding header is generated. If <string> is a zero-length string, then an Accept-Encoding header
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
