- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 12 Oct 2010 09:13:26 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: 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 Tue, Oct 12, 2010 at 5:07 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 11.10.2010 19:18, Adam Barth wrote: >>> >>> So, how about (for now): >>> >>> "...If this is a response message received by a user-agent, it either >>> SHOULD >>> be treated as error, or otherwise the message-body length SHOULD be >>> determined by reading the connection until it is closed; an error SHOULD >>> be >>> indicated to the user." >>> >>> ? >> >> 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. Adam
Received on Tuesday, 12 October 2010 16:14:28 UTC