This assumes that the client has an etag for the resource, in many of our use cases they will not. So the if-none-match approach will often fail. > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, September 07, 2007 12:04 AM > To: Yaron Goland > Cc: Henrik Nordstrom; James M Snell; HTTP Working Group > Subject: 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 > >Received on Friday, 7 September 2007 17:11:22 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC