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

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

-- Jamie