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

Re: clarification of 7.2.2. Monitoring Connections for Error Status Messages

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 19 Apr 2010 15:10:53 +1000
Cc: Wenbo Zhu <wenboz@google.com>, ietf-http-wg@w3.org
Message-Id: <1985F77A-2E10-4754-818D-4711C9AF8B74@mnot.net>
To: Jamie Lokier <jamie@shareable.org>
Well, it has to live with the consequences of sending that status line -- including the possibility that the request is malformed, incomplete, etc.

Many people have asked for a way for a server to change the status code, etc. once the status line has been sent (e.g., because they've encountered an error during streaming). AFAIK the only practical way to indicate a problem in HTTP (i.e., not in the body) is to make the response incomplete (usually by dropping the connection); while you could indicate something in trailers, not many people are able to or bother to check them.


On 19/04/2010, at 11:31 AM, Jamie Lokier wrote:

> Mark Nottingham wrote:
>> The server isn't required to wait for the entire request before sending a status. Is that what you're looking for?
> Ah, but is the server allowed to depend on receiving the remainder of
> the request after it has sent a non-error status?
> Section 7.2.2 talks about the client aborting the request body only in
> the cases of an "error status".
> -- Jamie

Mark Nottingham     http://www.mnot.net/
Received on Monday, 19 April 2010 05:11:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC