From: Isaac Boukris Date: Sat, 23 Apr 2016 12:52:04 +0000 (+0300) Subject: CURLOPT_ACCEPT_ENCODING.3: Follow-up clarification X-Git-Tag: curl-7_49_0~35 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=7987f5cb14d;p=thirdparty%2Fcurl.git 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 3d172dcbeb..c312631392 100644 --- 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