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