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

On Fri, May 14, 2010 at 1:24 AM, Henrik Nordström
<henrik@henriknordstrom.net> wrote:
> 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.
So I mis-read your comment - "Any change which will REQUIRE clients to
continue sending their request
body even after the server have responded will introduce incompatibility."

>
> 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.
Agreed. In practice, I'd expect clients advise the desire/capabilities
for receiving earlier response.


>
>> 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.
Good to know your experience on this.

>
>> 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.
>
> Regards
> Henrik
>
>

Received on Friday, 14 May 2010 21:48:24 UTC