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

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 UTC