CURLOPT_ACCEPT_ENCODING.3: clarified

As discussed in #785
This commit is contained in:
Daniel Stenberg 2016-05-01 13:29:11 +02:00
parent 22aa34f745
commit ffd0e6193f
1 changed files with 13 additions and 3 deletions

View File

@ -32,21 +32,31 @@ Pass a char * argument specifying what encoding you'd like.
Sets the contents of the Accept-Encoding: header sent in a HTTP request, and
enables decoding of a response when a Content-Encoding: header is received.
Three encodings are supported: \fIidentity\fP, which does nothing,
Three encodings are supported: \fIidentity\fP, meaning non-compressed,
\fIdeflate\fP which requests the server to compress its response using the
zlib algorithm, and \fIgzip\fP which requests the gzip algorithm.
If a zero-length string is set like "", then an Accept-Encoding: header
containing all built-in supported encodings is sent.
Set this option to NULL to explicitly disable it, which makes libcurl not send
an Accept-Encoding: header and not decompress contents automatically.
You can also opt to just include the Accept-Encoding: header in your request
with \fICURLOPT_HTTPHEADER(3)\fP 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 set (to any non-NULL value) or else any unsolicited encoding done by
the server is ignored. See the special file lib/README.encoding for further
details.
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 be
for the compressed content but sending the size for the non-compressed version
of the resource is a very common mistake.
.SH DEFAULT
NULL
.SH PROTOCOLS