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

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.

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

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

-- Jamie

Received on Friday, 14 May 2010 17:33:42 UTC