W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

From: Jamie Lokier <jamie@shareable.org>
Date: Fri, 7 Sep 2007 12:14:51 +0100
To: Yaron Goland <yarong@microsoft.com>
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20070907111451.GB14723@mail.shareable.org>

Yaron Goland wrote:
> In the Web3S case we are explicitly not trying to resolve this race
> condition. Our interest in 209 is strictly as an optimization. We
> often find ourselves in a situation where we want to issue a
> PUT/POST and we need to get the state back. Issuing a PUT/POST
> followed by a pipelined GET is expensive both because pipelining
> isn't well supported and because if the PUT/POST failed now the
> client has to receive and the server has to send a completely
> useless GET. So having the ability to ask for the GET response in
> the PUT/POST response is a very useful optimization to us.

Chained conditional requests would be a much more useful general
solution to this kind of problem.

Chained conditional requests are where a request will fail if an
earlier request has failed - or other conditions, such as an earlier
request succeeding in a particular way.

To preserve the connectionless nature of HTTP, it would be appropriate
for the references to earlier requests to use some persistent
client-specific id.  Alternatively, it might be acceptable to make
chained conditional requests a feature of persistent connection state.

This would solve a number of issues with pipelining.

Currently, a general purpose client has to go through complicated
heuristic contortions to decide when it is safe to pipeline requests -
and those heuristics are not completely reliable.

If later pipelined requests were sure to abort, with no side effects,
when an earlier request fails, or is more than a certain size, or is
delayed, or whatever (choose your condition), then there would be more
cases when it's safe for a client to send pipelined requests
speculatively, without fore-knowledge of the behaviour of each request.

(Chained conditional requests can be generalised further, to further
improve performance and predictability, if there is interest in the

-- Jamie
Received on Friday, 7 September 2007 11:15:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC