deflate (the zlib algorithm), gzip, br (brotli) and compress. A client requests that the server perform an encoding by including an Accept-Encoding header 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-Encoding header in the response. The value of the Content-Encoding header indicates which encodings were used to encode the data, in the order in which they were applied.Accept-Encoding header. See sec 3.1.2.2 of RFC 7231 for more information on the Content-Encoding header.deflate, gzip, zstd and br content encodings are supported by libcurl. Both regular and chunked transfers work fine. The zlib library is required for the deflate and gzip encodings, the brotli decoding library is for the br encoding and not too surprisingly libzstd does zstd.curl_easy_setopt][1](curl, [CURLOPT_ACCEPT_ENCODING][5], string)Accept-Encoding header.deflate, gzip, zstd 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, zstd and br. If a response is encoded using the compress or 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 containing all supported encodings will be generated.CURLOPT_ACCEPT_ENCODING][5] 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-Encoding type is not checked.--compressed][6] option with curl to cause it to ask servers to compress responses using any format supported by curl.