CURLOPT_ACCEPT_ENCODING.3: Follow-up clarification

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

See #785

diff --git a/docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.3 b/docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.3
index 3d172dcbeb671ac3e1f0955bf3ceb222098f7c6e..c3126313923cc7181fdff3cc14e62b5d69614c92 100644 (file)
--- a/docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.3
+++ b/docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.3
@@ -54,9 +54,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