From: Daniel Stenberg <daniel@haxx.se>
Date: Fri, 19 Dec 2025 09:14:14 +0000 (+0100)
Subject: CURLOPT_ACCEPT_ENCODING.md: warn about the expansion
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=481f11d96fdffa522962c43ce476467c40dfff49;p=thirdparty%2Fcurl.git

CURLOPT_ACCEPT_ENCODING.md: warn about the expansion

also mention it in KNOWN_RISKS.md

Closes #20031
---

diff --git a/docs/KNOWN_RISKS.md b/docs/KNOWN_RISKS.md
index 3773b94f86..6138df7f26 100644
--- a/docs/KNOWN_RISKS.md
+++ b/docs/KNOWN_RISKS.md
@@ -9,6 +9,8 @@ SPDX-License-Identifier: curl
 This is an incomplete list of known risks when running and using curl and
 libcurl.
 
+# Risks
+
 ## Insecure transfers
 
 When using curl to perform transfers with protocols that are insecure or the
@@ -136,3 +138,9 @@ authentication.
 
 curl users should consider switching to servers and options that use modern
 and secure algorithms.
+
+## Compression bombs
+
+When asking curl or libcurl to automatically decompress data on arrival, there
+is a risk that the size of the output from the decompression process ends up
+many times larger than the input data size.
diff --git a/docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.md b/docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.md
index 05e7d19a35..6594061504 100644
--- a/docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.md
+++ b/docs/libcurl/opts/CURLOPT_ACCEPT_ENCODING.md
@@ -56,18 +56,19 @@ You can also opt to just include the Accept-Encoding: header in your request
 with CURLOPT_HTTPHEADER(3) but then there is 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.
+Setting this option is a request, not an order; the server may or may not do
+it. It must be set (to any non-NULL value) or else any encoding done by 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
-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).
+The Content-Length: header field 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).
 
 The application does not have to keep the string around after setting this
 option.
@@ -75,6 +76,9 @@ option.
 Using this option multiple times makes the last set string override the
 previous ones.
 
+**WARNING**: when decompressing data, even tiny transfers might be expanded
+and generate a huge amount of bytes.
+
 # HISTORY
 
 This option was called CURLOPT_ENCODING before 7.21.6