deflate(the zlib algorithm),
compress. A client requests that the server perform an encoding by including an
Accept-Encodingheader in the request document. The value of the header should be one of the recognized tokens
deflate, ... (there's a way to register new schemes/tokens, see sec 3.5 of the spec). A server MAY honor the client's encoding request. When a response is encoded, the server includes a
Content-Encodingheader in the response. The value of the
Content-Encodingheader indicates which encodings were used to encode the data, in the order in which they were applied.
Accept-Encodingheader. See sec 220.127.116.11 of RFC 7231 for more information on the
brcontent encodings are supported by libcurl. Both regular and chunked transfers work fine. The zlib library is required for the
gzipencodings, the brotli decoding library is for the
brencoding and not too surprisingly libzstd does
brcontent encodings, so the only values for [
CURLOPT_ACCEPT_ENCODING] that will work (besides
identity, which does nothing) are
br. If a response is encoded using the
compressor methods, libcurl will return an error indicating that the response could not be decoded. If
<string>is NULL no
Accept-Encodingheader is generated. If
<string>is a zero-length string, then an
Accept-Encodingheader containing all supported encodings will be generated.
CURLOPT_ACCEPT_ENCODING] must be set to any non-NULL value for content to be automatically decoded. If it is not set and the server still sends encoded content (despite not having been asked), the data is returned in its raw form and the
Content-Encodingtype is not checked.
--compressed] option with curl to cause it to ask servers to compress responses using any format supported by curl.