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: Wenbo Zhu <wenboz@google.com>
Date: Tue, 20 Apr 2010 01:54:49 -0700
Message-ID: <z2h83c4e7ff1004200154hfcd6b69eh74147249dcc132a2@mail.gmail.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
On Mon, Apr 19, 2010 at 6:36 AM, Jamie Lokier <jamie@shareable.org> wrote:
> 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.

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



>
> 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
>
Received on Tuesday, 20 April 2010 08:55:18 GMT

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