RE: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

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
>
>