W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: [#95] Multiple Content-Lengths

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 11 Oct 2010 10:18:08 -0700
Message-ID: <AANLkTimbx1KWrCUJpMD=FFPvk_Jkq4aWqma3+GscEytV@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: (wrong string) ™ˆ™˜Œ) <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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:28 GMT