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

Re: i28 proposed replacement text

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
Message-ID: <20080603212913.GG26787@polar.elf12.net>

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

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