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

From: Wenbo Zhu <[email-masked]>
Date: Thu, 15 Apr 2010 16:44:00 -0700

As a client is sending a message-body over the network connection,
will any non-error response status (as well as the message body) be
allowed, at all?

Section 7.2.2 & 5.0 seems to suggest otherwise, but not strongly enough IMO.

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09

"
5.  Response

   After receiving and interpreting a request message, a server responds
   with an HTTP response message.

7.2.2.  Monitoring Connections for Error Status Messages

   An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
   the network connection for an error status while it is transmitting
   the request.  If the client sees an error status, it SHOULD
   immediately cease transmitting the body.  If the body is being sent
   using a "chunked" encoding (Section 6.2), a zero length chunk and
   empty trailer MAY be used to prematurely mark the end of the message.
   If the body was preceded by a Content-Length header, the client MUST
   close the connection.
"

- Wenbo

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Apr 2010 11:16:07 +1000

The server isn't required to wait for the entire request before sending a status. Is that what you're looking for?

--
Mark Nottingham     http://www.mnot.net/

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 15 Apr 2010 18:18:56 -0700

> The server isn't required to wait for the entire request before sending a status. Is that what you're looking for?
more precisely, the message body as well ... and yes, I want to know
if the spec explicitly disallows such behavior.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Apr 2010 11:20:47 +1000

It doesn't disallow it.

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 15 Apr 2010 18:31:19 -0700

> It doesn't disallow it.
That's how I read it too ..

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 19 Apr 2010 02:31:59 +0100

> 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

---

From: Wenbo Zhu <[email-masked]>
Date: Sun, 18 Apr 2010 22:04:49 -0700

> the request after it has sent a non-error status?
Good question. I'd say yes .... or this is no worse than in typical
cases where it is possible that the server may fail to generate the
complete response as committed to the client (e.g. by flushing the
headers).

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Apr 2010 15:10:53 +1000

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.

Cheers,

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 19 Apr 2010 13:36:05 +0100

> Well, it has to live with the consequences of sending that status line -- including the possibility that the request is malformed, incomplete, etc.

Ah, but according to the spec, that should not be a consequence.

If you send an "error status" an incomplete request is to be expected.
The server shouldn't rely on getting the whole request.

But if you send a non-error status, the spec doesn't suggest the
client truncates the request - no more than normal anyway.  So the
server should be able to depend on getting the request just as much as
if it hadn't sent the status yet (barring client implementation quirks).

Are you saying the spec is incomplete in this regard?

-- Jamie

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Apr 2010 22:52:48 +1000

No; I think we're saying the same thing; that HTTP servers can't* violate the linear nature of time, in that if they choose to send the response before getting the full request, there are still things they don't know about that request. 

Cheers,

* lacking a madman with a blue box, of course.

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 19 Apr 2010 14:36:05 +0100

Mark Nottingham wrote:
> No; I think we're saying the same thing; that HTTP servers can't*
> violate the linear nature of time, in that if they choose to send the
> response before getting the full request, there are still things they
> don't know about that request.

No :-) that's not what I'm suggesting.

Consider a server which takes a POST request and returns an exact copy
of the body with all the characters changed to upper case, at the same
time as it receives the request.

That doesn't violate time and it can be streamed.  (I have tested it
with some clients, and it works... with some.)  But it does send the
*status* before receiving the whole request.

Consider also a POST request uploading a large video file.  The
response could be streaming HTML indicating the progress.

Consider also Comet-style apps which could use one connection instead of two.

Now, we can't do any of those things because it doesn't work with most
clients.

But the spec does not appear to support those clients not working.

-- Jamie

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 20 Apr 2010 01:54:49 -0700

> response could be streaming HTML indicating the progress.

Yes, these are exactly the type of use cases this question comes from ...

IMO, early non-error response does seem to violate the basic RPC
scheme that is assumed in HTTP. From reading the charter of this WG, I
am not sure if we choose to allow, explicitly, such interaction
semantics, will it introduce any incompatibility?

Non-error status doesn't necessarily guarantee a complete/successful
response, e.g. server processing, networking may fail any way.. The
real issue is that clients/proxies alike need be prepared to receive
responses when requests are still under transmission.

If the spec does allow such behavior, then the possible requirements would be:
1) server: once a non-error status has been sent out to the client,
any future request error should result in aborting the connection; (as
pointed out earlier)
2) client: if an early non-error status has been received, keep
sending out remaining request body as long as the connection stays
open;
3) proxy: may choose to buffer request or response as usual.

Also, when POST is against a "processing resource", one may argue
(i.e. pretend) that the REST concept still applies.

- Wenbo