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

From: Wenbo Zhu <[email-masked]>
Date: Fri, 14 May 2010 00:13:13 -0700

This email is a follow-up to the previous thread - "clarification of
7.2.2. Monitoring Connections for Error Status Messages". Thanks for
all the replies!

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

1. a non-error response status implies/requires the server seeing the
complete request body.
==> 200 status doesn't necessarily guarantee a complete/successful
response end-to-end, due to interim server-processing or communication
failure (Wenbo Zhu).

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)

3. proxies may have problems to continue transmitting request data
after the response arrives.
==> most of them are able to handle response data when the request is
still in transmission (Henrik Nordström)

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.

- Wenbo

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 14 May 2010 10:24:46 +0200

> 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

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.

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

> after the response arrives.

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

> are disallowed, to avoid possible ambiguity.

I have a different view in this matter obviously.

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 14 May 2010 18:33:12 +0100

> must not deadlock if the transmit queue to the client gets full.

Agreed, exactly.

> 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
                                                           ^^^^^^^^^
> 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?

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

> 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

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 14 May 2010 20:09:36 +0200

> would actually be useful.

There is applications operating in this manner, but the HTTP transport
isn't well suited for this as you have no control over any buffering
done by intermediary servers or even clients http frameworks operate.

> that when it knew the client supported it.

Yes, and such clients do exists, even if most select to either do it
over an SSL connection or by using two parallell requests.

> Then the sticking point would be what proxies do.

Depends on the purpose of the proxy.

> alternatively of not accepting those?

None, other than me reading a bit too quickly.

> comet-style interactions.

It will work in most environments, but you will find networks where
intermediary proxies do buffer considerable amount of data or which may
even serialize it down to request->response pattern.  HTTP does not
provide any guarantee that full duplex communication will work.

> in favour of the spec reflecting reality, instead of ignoring it.

Depends on where you draw the boundary for the client. If you include
the end user behavior in the client then most users do not wait for
their browser to finish sending something if they have already got the
response they are expecting.

Most if not all clients if left alone by their user will happily
continue sending the request without interruption provided the server
does not close the connection on them.

But some clients or intermediaries MAY get confused and think they are
done when the server response is completed. This is however not
something which is supported by the specifications and the cases I have
seen has been pure bugs and not intentional.

Regards
Henrik

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 14 May 2010 14:47:28 -0700

>> compatible with the spec, on the following grounds:
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."

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

> Yes, but I would expect most if not all to have fixed that by now.
Good to know your experience on this.

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 14 May 2010 15:04:32 -0700

>> must not deadlock if the transmit queue to the client gets full.
I'll add time-out too, although some of these concerns may be
implementation specific.

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

> in favour of the spec reflecting reality, instead of ignoring it.
OK.

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 14 May 2010 15:16:35 -0700

> provide any guarantee that full duplex communication will work.
True.

Then the question remains: 1) the behavior is disallowed by the spec
as it's not reliable - due to proxies (if not ideologically); or 2)
the behavior is supported, with all the implementation caveats and
related best-effort/fall-back concerns.
I am less concerned about breaking existing clients, as such a
behavior is completely controlled by the server, and specially enabled
for custom applications.

---

From: Henrik Nordström <[email-masked]>
Date: Sat, 15 May 2010 09:48:37 +0200

> related best-effort/fall-back concerns.

Imho 2.

It is certainly the case that servers are allowed to respond early
before they have received the whole request. The only caveat there is
that the server must not block on writing if the client doesn't read the
response yet and need to continue reading the request while it's sending
the response.

It is also the case that the spec do not require clients to abort the
request if seeing an early non-error response.

Imho the case of a server that streams the response as the request is
coming in is a perfectly legal application of HTTP. An example of such
service whould be a translation service which translates on the fly
without buffering the whole request.

But it's very unusual behavior to complete the response down to the
final octet and signal end of response and still require the rest of the
request to be sent, and I would advice to stay away from any such
designs. Better make sure that there is some part of the response left
to send after receiving all of the request. Could be as little as the
end chunk when using chunked encoding or connection close if using
neither content-length or chunked. As long as you don't signal
end-of-response until all of the request have been received.

Regards
Henrik

---

From: Wenbo Zhu <[email-masked]>
Date: Sat, 15 May 2010 03:13:42 -0700

So at least we agree that there are valid use cases for supporting
concurrent responses; and the spec at least hasn't explicitly
disallowed such a behavior.

I briefly searched the mailing-list archive, and wasn't sure if this
subject has been brought up before. Regardless of which interpretation
httpbis chooses to support, there certainly have been enough
confusions among implementors that warrant further clarification in
the spec.

While there still may be incompatibility concerns, I'd be happy to see
that the spec permits concurrent (early) response, to avoid
introducing any non-compatible behaviors in implementing HTTP based
protocols.

- Wenbo

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 16 May 2010 22:48:14 +0200

> disallowed such a behavior.

Spec allows early responses, and in specific requires clients to act in
specific manner if the early response is an error response.

the fuzzy spot is if servers can expect the rest of the request to be
sent to them even if they finish the complete response before receiving
the complete request.

then there is a number of implementation details like store & forward
operating proxies etc which will have impact on the delivered timing, so
you cant rely on the early aspect to actually be delivered. It may well
be that the server won't receive anyting (not even a connection) before
the HTTP request is completely sent by the client.

Regards
Henrik

---

From: Wenbo Zhu <[email-masked]>
Date: Sun, 16 May 2010 17:30:18 -0700

> the HTTP request is completely sent by the client.
A more general question is how well proxies support chunk-encoded
requests today, since browsers don't generate chunk-encoded requests.
Would like to hear your experiences on this

Thanks,
Wenbo

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 17 May 2010 08:48:58 +0200

> Would like to hear your experiences on this

I would be expect all to either handle chunked or immediately respond
with 411 today.

But yes, it's still fairly infrequently used and there may be bugs
lurking.

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 19 May 2010 03:51:24 +0100

> But yes, it's still fairly infrequently used and there may be bugs

Do you know of any instances where it's used, other than for testing?

Thanks,
-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 19 May 2010 03:53:03 +0100

> response yet and need to continue reading the request while it's sending

I agree.

> end-of-response until all of the request have been received.

I agree with the above - it's good advice.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 19 May 2010 03:59:13 +0100

> provide any guarantee that full duplex communication will work.

It's true, but isn't that less to do with bidirectional streaming, and
more of a general "can't rely on unidirectional streaming either"?

Elsewhere I've failed to get a straight answer as to whether
(unidirectional) streaming parts of a response (hanging-GET style) is
unreliable enough, these days, to warrant sending each part in a whole
response of its own.

And if it is unreliable enough - whether that's due to proxies or
clients, or both.  If I knew the proxies were fine and the
difficulties were due to client buffering, then I would know it's safe
to use with clients that I recognise as being ok with it.

I've seen a hanging-GET style specification that did streaming, but
followed every part with some arbitrary looking number of space
characters to force it through - no explanation of why that number,
whether it's believed to always be enough from experience, or which
proxies or clients needed it, of course.

-- Jamie

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 19 May 2010 09:32:39 +0200

> Do you know of any instances where it's used, other than for testing?

Have seen it in live traffic generated by non-browser clients.

Not sure which however.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 19 May 2010 09:39:52 +0200

> more of a general "can't rely on unidirectional streaming either"?

Correct.

> unreliable enough, these days, to warrant sending each part in a whole

You will find networks where this do not work.

But as with most things it will work fine for the majority of users.

> clients, or both.

proxies mainly.

> proxies or clients needed it, of course.

Probably to escape from TCP send segment buffering optimization either
in the server itself or possibly proxies along the path. But all proxies
I know by default disable such buffering to support streaming responses.

Regards
Henrik

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 19 May 2010 09:41:40 +0200 (CEST)

> Have seen it in live traffic generated by non-browser clients.

curl does Chunked-Encoded requests by default if you for example ask it to 
send PUT data read from stdin. And of course libcurl provides this ability so 
other applications using that could very well use it.

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 May 2010 09:50:08 +0200

On 17.05.2010 02:30, Wenbo Zhu wrote:
> ...
> ...

My company used to work on a WebDAV client component in SAP Netweaver's 
Knowledge Management (for connecting remote WebDAV servers). We 
certainly used chunked encoding in requests (serializing WebDAV XML). We 
occasionally had issues with that, but as far as I recall that was 
because of broken origin servers (subsequently being fixed), not proxies.

Best regards, Julian

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 28 May 2010 12:34:48 -0700

Thanks for everyone who has replied to this thread.

Given that valid use cases do exist and the current HTTP spec hasn't
explicitly disallowed concurrent bi-directional communication, I have submit
a draft document as "Implications of Full-Duplex HTTP (
http://tools.ietf.org/id/draft-zhu-http-fullduplex-01.txt)". The purpose of
this draft is to encourage public adoption of full-duplex HTTP and as well
to help incorporating full-duplex HTTP into other open protocols.

Comments/corrections are very much welcome!

- Wenbo
<http://tools.ietf.org/id/draft-zhu-http-fullduplex-01.txt>

On Wed, May 19, 2010 at 12:50 AM, Julian Reschke <[email-masked]>wrote:

> Knowledge Management (for connecting remote WebDAV servers). We certainly
> used chunked encoding in requests (serializing WebDAV XML). We occasionally
> had issues with that, but as far as I recall that was because of broken
> origin servers (subsequently being fixed), not proxies.
>
>
> Best regards, Julian
>