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: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 07 Sep 2007 09:04:05 +0200
Message-ID: <46E0F7E5.2000000@gmx.de>
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>

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
Received on Friday, 7 September 2007 07:04:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT