On 14 May 2013, at 11:56 PM, Roy T. Fielding <field...@gbiv.com> 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. >> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-4.1 >> 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? Regards, Graham --
