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

On Fri, May 14, 2010 at 10:33 AM, Jamie Lokier <jamie@shareable.org> wrote:
> Henrik Nordström 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.
>>
>> 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.
>
> Agreed, exactly.
I'll add time-out too, although some of these concerns may be
implementation specific.

>
>> > 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.
>
> Of course, but it's one thing for that to be permitted when there is a
> reason (such as client aborting), and quite another for it to be the
> recommended behaviour in non-error circumstances.
>
>> 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.
>
> What is "already responded"?
>
> We aren't just talking about when the server has finished responding;
> we're talking about when the client has received part of the response,
> but not all of it.
>
> It is possible to implement servers where the response is an
> incremental function of the request, and if it worked reliably, that
> would actually be useful.
>
> It doesn't work reliably, but as far as I can tell, the spec says
> nothing about it one way or another.  It's just historical that some
> clients support that and some don't.
>
> As far as I can tell, it would be within the HTTP specs if a new
> client was deliberately made which supported bidirectional streaming
> POSTs over a single connection, and a new server took advantage of
> that when it knew the client supported it.
>
> Then the sticking point would be what proxies do.
>
>> > 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).
>
> That requirement says nothing about *non-error* codes.  What part of
> accepting those while continuing to send the request is broken?  Or
> alternatively of not accepting those?
>
>> > 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.
>
> Do you think the above idea, of a client supporting it and a server
> making use of it if it knows the particular client supports it, would
> work now?  That would halve the number of connections needed for
> comet-style interactions.
This is one of the benefits. More importantly, POST are
non-idempotent, and concurrent request/response would enable real-time
duplex communication.
Also, as I mentioned earlier, if we consider the target resource a
"processing resource", e.g. voice translation ... then even the REST
principle still holds.

>
>> > 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.
>
> I mostly agree with Henrik, but if it's already common practice for
> clients to abort when they see part of a non-error response, then I'm
> in favour of the spec reflecting reality, instead of ignoring it.
OK.

>
> -- Jamie
>

Received on Friday, 14 May 2010 22:05:03 UTC