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

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Mar 2008 15:45:48 +1100

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       [email-masked]

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 13 Mar 2008 23:17:53 +0100

> > using a status code of 200 (OK).

I don't see how it conflicts. If there is a more fatal condition
underlying the "temporary/network failure" (as seen by the client/proxy)
then this will be found out when attempting to fill in the gaps.

Regards
Henrik

---

From: Robert Siemer <[email-masked]>
Date: Sat, 15 Mar 2008 22:32:28 +0100

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

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