- From: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
- Date: Tue, 3 Jun 2008 23:29:14 +0200
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- 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
> > Maybe something like "final-status" as a new response header would make > > sense. That way, a server could send an initial 2xx, start sending > > content, and in case of internal errors could at least signal that > > something went fatally wrong... > > Problem there is that recipients are not required to care about trailers > and those who don't will misread the response as 100% successful.. so > you are better off simply closing the connection in the middle of the > response and log the error locally. The next-hop will notice the error, > but there is no guarantee the final recipient will.. > > The scope of this WG is to clarify HTTP/1.1 and correct errors, not > HTTP/1.2 (or 2.0) fixing the shortcomings of HTTP/1.1. 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. 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). 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). What about unsafe methods? Robert
Received on Tuesday, 3 June 2008 21:28:44 UTC