From 7987f5cb14dc2fae5921ac3a2989a7d0e51474d2 Mon Sep 17 00:00:00 2001
From: Isaac Boukris <iboukris@gmail.com>
Date: Sat, 23 Apr 2016 15:52:04 +0300
Subject: [PATCH] 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
---
 docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.3 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

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
-- 
GitLab