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

Indicating response errors after the status-line is sent

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Wed, 5 Mar 2008 15:45:48 +1100
Message-Id: <74FB84A2-03BF-4655-B8A3-2C528C980B49@yahoo-inc.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>


8.1.4:
> A client, server, or proxy MAY close the transport connection at any  
> time.
[...]
> Servers SHOULD NOT close a connection in the middle of transmitting  
> a response, unless a network or client failure is suspected.


Besides the obvious conflict here (which I think is just an editorial  
issue, at the most; reading them in context isn't as bad), I've heard  
some people advocate closing the connection abruptly (on a response,  
from the server side) if the server finds that the status code it has  
already sent isn't appropriate (e.g., it's streaming a response and  
has a catastrophic error), as a way to indicate an error.

Thoughts? Does such a practice conflict with this:

> 13.8 Errors or Incomplete Response Cache Behavior
> A cache that receives an incomplete response (for example, with  
> fewer bytes of data than specified in a Content-Length header) MAY  
> store the response. However, the cache MUST treat this as a partial  
> response. Partial responses MAY be combined as described in section  
> 13.5.4; the result might be a full response or might still be  
> partial. A cache MUST NOT return a partial response to a client  
> without explicitly marking it as such, using the 206 (Partial  
> Content) status code. A cache MUST NOT return a partial response  
> using a status code of 200 (OK).

Cheers,


--
Mark Nottingham       mnot@yahoo-inc.com
Received on Wednesday, 5 March 2008 04:46:17 GMT

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