curl / Mailing Lists / curl-library / Single Mail


CURLOPT_ACCEPT_ENCODING and unknown / unsolicited encodings

From: Rainer Canavan via curl-library <>
Date: Wed, 22 Aug 2018 16:43:58 +0200

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
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 (and its
predecessors) since 019c4088cf from April 2003 (with a minor error,
see patch).
on the other hand does not specify how unknown encodings are handled -
I would suggest copying the relevant sentece from in

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
sane method?



Received on 2018-08-22