- From: Adrien de Croy <adrien@qbik.com>
- Date: Wed, 13 Oct 2010 09:47:26 +1300
- To: Willy Tarreau <w@1wt.eu>
- CC: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>, "William Chan (?????????)" <willchan@chromium.org>, "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 13/10/2010 7:40 a.m., Willy Tarreau wrote: > On Tue, Oct 12, 2010 at 09:38:57AM -0700, Adam Barth wrote: >> On Tue, Oct 12, 2010 at 9:21 AM, Julian Reschke<julian.reschke@gmx.de> wrote: >>> On 12.10.2010 18:13, Adam Barth wrote: >>>>>> I would say: >>>>>> >>>>>> "...If this is a response message received by a user-agent, it MUST >>>>>> be treated as error." >>>>>> >>>>>> (or at the SHOULD-level if you're scared of MUST-level requirements). >>>>> Well, "MUST be treated as error" isn't really helpful; it doesn't require >>>>> any observable behavior. >>>>> >>>>> That a response message like this *is* broken is a statement of fact; the >>>>> question is whether we want to require any specific handling. So, for >>>>> instance, do we want to forbid any of the behaviors we see today? (use >>>>> the >>>>> first value/use the second value/use until end of connection)? >>>> I see. I meant that the user agent MUST close the socket and ignore >>>> the response, or whatever the HTTP spec idiom is for instructing the >>>> user agent to treat this response as a fatal error. >>> Yes. As a matter of fact, my proposal wasn't better in that aspect :-) >>> >>> So... >>> >>> "If this is a response message received by a user-agent, it SHOULD be >>> treated as in error by ignoring the message and closing the connection." >> SGTM. > I'm realizing that this is very similar to the chunked-encoding with > content-length. I wonder whether we have numbers on the cases where > this still happens, because the risks of bad handling are exactly the > same, even though the spec says that chunking must be assumed in this > case. It would be nice if numbers showed that we could simply consider > that situation as an error. > I agree. The current spec presumes it's an innocent error that a Content-Length header sneaked in, and really it's meant to be chunked if there's a Transfer-Encoding: chunked header. However for any other problem scenario, this leads to other issues which show up as malformed chunks if you're lucky. I'm struggling to see how this could be used in an attack though. regards Adrien > Regards, > Willy > > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Tuesday, 12 October 2010 20:48:02 UTC