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