Re: Concurrent non-error response disallowed. ("clarification of 7.2.2. Monitoring Connections for Error Status Messages")

fre 2010-05-14 klockan 00:13 -0700 skrev Wenbo Zhu:

> We seem to agree that "concurrent" non-error response is NOT
> compatible with the spec, on the following grounds:

No we don't.

Imho servers may well answer early if they like, and many do.

But any servers answering early must
* continue to accept the body of the request
* be prepared that the client maybe will terminate the request after it
has got the response (or even before, see below).
* handle properly the case that the client is maybe will not read the
response until it has sent the complete request. The request processing
must not deadlock if the transmit queue to the client gets full.

> 1. a non-error response status implies/requires the server seeing the
> complete request body.

No. There is nothing that ever forces clients to send the complete body.
Both server and client are always permitted to terminate the request at
any time they like. The fact that the server have already responded do
not change this, but in fact makes it somewhat more likely the client
won't be interested in sending the rest of the body.

> 2. existing clients won't be able to handle concurrent non-error
> responses, i.e. when the request is still in transmission.
> ==> some clients do seem to "work" (Jamie Lokier)

Then those are broken. The requirement to monitor for error codes have
been there since at least RFC2616 (1999).

> 3. proxies may have problems to continue transmitting request data
> after the response arrives.

Yes, but I would expect most if not all to have fixed that by now.

> However, as Mark Nottingham pointed out at the same time, the above
> interpretation isn't explicitly supported by the current
> specification. Therefore I suggest the spec include a clear
> clarification on the requirement that concurrent non-error responses
> are disallowed, to avoid possible ambiguity.

I have a different view in this matter obviously.


Received on Friday, 14 May 2010 08:25:23 UTC