- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 11 Oct 2010 10:18:08 -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 Mon, Oct 11, 2010 at 5:56 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 08.10.2010 22:41, Adam Barth wrote: >> Great. At that frequency of occurrence, we should just fail the >> request with a fatal error and close the socket. I don't see any >> reason to partially render the page. >> ... > > The current text > (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-11.html#rfc.section.3.3.p.8>) > says: > > "...If this is a response message received by a user-agent, the message-body > length is determined by reading the connection until it is closed; an error > SHOULD be indicated to the user." > > Given the experiment with Chrome, we need to allow that behavior as well, > but are we ready to require it? > > 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). IMHO, reading to the end of the connection is neither a good idea for security nor necessary for compatibility (given that this case occurs sufficiently infrequently). I've also removed the user interface requirements because I don't think the spec should have any user interface requirements. Adam
Received on Monday, 11 October 2010 17:19:20 UTC