cURL / Mailing Lists / curl-library / Single Mail



From: Daniel Stenberg <>
Date: Mon, 24 Oct 2011 16:16:39 +0200 (CEST)

On Wed, 19 Oct 2011, Dan Fandrich wrote:

> Test 46 fails when building curl in debug mode with CURL_MAX_WRITE_SIZE set
> to a low value (like 400), as can be seen on this autobuild:
> The issue is
> the write size sanity check that's performed in debug mode in tool_write_cb.
> If the amount of data to be written is larger than CURL_MAX_WRITE_SIZE, that
> function returns with an error.

That check is rather a mistake, and a proof that we need to change the
documentation and educate users of what to accept in regards to sizes when
headers are passed to the header callback (and when headers have been
requested to get sent to the write callback).

Since libcurl offers the application the "service" of concatenating all
headers into single line headers and then only pass full headers to the
callback, there will indeed be times when the header is longer than
CURL_MAX_WRITE_SIZE. In fact, it is easy to just return a header right now
that is longer than 16K and it'll trigger that check in the tool code!

I'll change some code and commit the test once the code runs.

Also, the CURL_MAX_WRITE_SIZE define is a bit overused internally and we
should try to not have as many data buffers depend on that size when we more
or less encourage users to change it, while lots of buffers internally that
use that define (most implicitly via BUFSIZE) will require a decent minimum

> 2) say that CURL_MAX_WRITE_SIZE only refers to the maximum size of data
> blocks and that header blocks can be larger, and remove that size check from
> the curl tool entirely (or just demote it to a warning).

libcurl currently allows received HTTP headers to be up to 100K. There's a
fixed limit size only to prevent that from becoming an attack vector for rogue
servers if someone would return a "never-ending" header.

List admin:
Received on 2011-10-24