httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: RFC: Handling abnormally large chunk sizes
Date Wed, 15 May 2013 09:05:17 GMT
On 14 May 2013, at 11:56 PM, Roy T. Fielding <> wrote:

>> I am currently getting to the bottom of a test case that checks httpd's response
to an abnormally large chunk extension from a reverse proxy server. What httpd does now is
trigger an error, causing both the upstream and downstream connections to be terminated and
truncated. Is this the correct way to respond to this?
> Is there any other way to handle it?  How long are we talking about?
> I certainly wouldn't try to process more than a single input buffer.

The test attempts a chunk-ext length of just over 16k, which is big enough to trigger the
HTTP_IN filter to error out with APR_ENOSPC. Because the status and headers have already been
sent, httpd has no choice but to just terminate the connection.

>> says this:
>> "All recipients MUST be able to receive and decode the chunked transfer coding and
MUST ignore chunk-ext extensions they do not understand."
>> Does the above "they do not understand" requirement include the requirement to ignore
chunk-ext extensions that are too long? (For some arbitrary definition of long)
> Probably, but we can fix the requirement if you think it might be
> a security issue (or just a bit too silly).  Note that sending
> chunk-ext has been deprecated.

It seems there is no formal definition in the spec as to the MUST behaviour should a proxy
be unable (eg bogus chunk length "ZXY") or unwilling (because of size) to decode a chunk.

What should the proxy do in this case?


View raw message