Re: Indicating response errors after the status-line is sent

On Wed, Mar 05, 2008 at 03:45:48PM +1100, Mark Nottingham wrote:

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

That technique is not limited to inappropriate status codes: the 
response body could now be undesired based on a late event.

> 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).

I do not see conflicts here. - The problem I see is that some HTTP 
clients silently accept aborted responses as complete.


Robert

Received on Saturday, 15 March 2008 21:31:55 UTC