Follow up clarification on CURLOPT_ACCEPT_ENCODING

Clarify that CURLOPT_ACCEPT_ENCODING has to be explicitly disabled
only if it was previously enabled (as the default is NULL).

Mention possible content-length mismatch with sum of bytes reported
by write callbacks when auto decoding is enabled.

See curl#785

docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.3

@@ -39,8 +39,9 @@ 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.
+Set this option to NULL to explicitly disable it (in case it was previously
+enabled on the CURL handle), 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
@@ -54,9 +55,10 @@ 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.
+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).
 .SH DEFAULT
 NULL
 .SH PROTOCOLS