CURLOPT_ACCEPT_ENCODING.md: warn about the expansion

also mention it in KNOWN_RISKS.md

Closes #20031
This commit is contained in:
Daniel Stenberg 2025-12-19 10:14:14 +01:00
parent 26d3b9e7b9
commit 481f11d96f
No known key found for this signature in database
GPG Key ID: 5CC908FDB71E12C2
2 changed files with 19 additions and 7 deletions

View File

@ -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.

View File

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