W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: i28 proposed replacement text

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Wed, 04 Jun 2008 19:55:21 +0200
To: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
Cc: Julian Reschke <julian.reschke@gmx.de>, Jamie Lokier <jamie@shareable.org>, Yves Lafon <ylafon@w3.org>, Joe Orton <joe@manyfish.co.uk>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
Message-Id: <1212602121.7235.12.camel@hlaptop.henriknordstrom.net>

tis 2008-06-03 klockan 23:29 +0200 skrev Robert Siemer:
> Exactly. - The parties who care about message truncation should not use 
> a connection closure as message end indication. Likewise 
> should intermediaries not change the message end indication method if 
> they don't have the full message yet.

Fully agreed.

The thing I oppose is texts indicating that chunked encoding provides a
guaranteed integrity. It does not. If you want something which provides
a reasonable guarantee then Content-Length must be used.

> But one question stays: should a client/proxy retry if it detects a 
> truncated message? - As I read RFC2616: yes (especially if the method is 
> safe).

Perfectly fine for user agents, but not so sure about proxies. But the
partial response MAY be cached and completed using range requests.

> Firefox 2.x did not do that. - I didn't even warn the user or something 
> if it had a clear indication that something is missing (response with 
> Content-Length: and premature connection close).

Detected truncated messages really SHOULD be considered invalid. This
includes both chunked encoding closed without seeing the end chunk, or
connection closed without seeing all of the response as indicated by
Content-Length. Both cases indicates without any doubt that something
went very wrong with the message.

It's clearly wrong to process them as if they were completely valid
messages.

Regards
Henrik
Received on Wednesday, 4 June 2008 18:57:27 GMT

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