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.

Introducing a new status code (and new headers to select server 
behavior) just for a performance optimization IMHO isn't a good idea. 
What's clear here is that we have to separate use cases, and 209 as 
proposed can't do both.

With respec to:
	
	"...and because if the PUT/POST failed now the client has to receive 
and the server has to send a completely useless GET."

That can be fixed by using a conditional GET, right? Such as:

PUT /resource HTTP/1.1
If-Match: "123"
...

GET /resource HTTP/1.1
If-None-Match: "123"
...

With the conditional GET, if the PUT failed the client will only get a 
304 Not Modified, so won't have to read the new content (or close the 
connection).

Best regards, Julian