easy:SetOpt_Accept_Encoding(enc)
Sets the contents of the Accept-Encoding: header sent in an HTTP request, and enables decoding of a response when a Content-Encoding: header is received.
libcurl potentially supports several different compressed encodings depending on what support that has been built-in.
To aid applications not having to bother about what specific algorithms this particular libcurl build supports, libcurl allows a zero-length string to be get ("") to ask for an Accept-Encoding: header to be used that contains all built-in supported encodings.
Alternatively, you can specify exactly the encoding or list of encodings you
want in the response. Four encodings are supported: identity, meaning
non-compressed, deflate which requests the server to compress its
response using the zlib algorithm, gzip which requests the gzip
algorithm and (since curl 7.57.0) br which is brotli. Provide them in
the string as a comma-separated list of accepted encodings, like:
"br, gzip, deflate". |
Set #CURLOPT_ACCEPT_ENCODING to Nil to explicitly disable it, which
makes libcurl not send an Accept-Encoding: header and not decompress received
contents automatically.
You can also opt to just include the Accept-Encoding: header in your request
with #CURLOPT_HTTPHEADER but then there will be no automatic
decompressing when receiving data.
This is a request, not an order; the server may or may not do it. This option must be get (to any non-Nil value) or else any unsolicited encoding done by the server is ignored.
Servers might respond with Content-Encoding even without getting a Accept-Encoding: in the request. Servers might respond with a different Content-Encoding than what was asked for in the request.
The Content-Length: servers send for a compressed response is supposed to indicate the length of the compressed content so when auto decoding is enabled it may not match the sum of bytes reported by the write callbacks (although, sending the length of the non-compressed content is a common server mistake).