- 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
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 UTC