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

What's the use case for wanting to resolve this race condition? If someone issues a change to a resource and someone else issues a subsequent change to alter the resource's state again then who cares what the interim state was since it is now gone?

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.

        Thanks,

                        Yaron



> -----Original Message-----
> From: Henrik Nordstrom [mailto:henrik@henriknordstrom.net]
> Sent: Thursday, August 30, 2007 5:01 AM
> To: Yaron Goland
> Cc: James M Snell; HTTP Working Group
> Subject: RE: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]
>
> On ons, 2007-08-29 at 17:34 -0700, Yaron Goland wrote:
>
> > In my current spec I threw in some language that basically says that
> a 209 response might include content that goes beyond the changes in
> the associated method. E.g. in theory the following is legal according
> to my spec:
> > Time 0 - Issue PUT with Web3SGetResponse Time 1 - PUT succeeds Time 2
> > - Another method that changes the resource's state is successfully
> > executed Time 3 - The 209 response body to the PUT received at Time 0
> > is created and returned It isn't clear to me if this behavior is
> legal according to the PATCH spec.
> >
> > Also I put in some text that said that 209s can, in theory, be
> returned even if a client hasn't specified Web3SGetResponse but it
> isn't encouraged. I wasn't sure if this is legal according to the PATCH
> spec.
>
> From what I can tell this family of race conditions is the main
> motivation for the 209 response code.
>
> Consider the following:
>
> Time 0 - Client A issues PUT request
> Time 1 - PUT 'A' succeeds
> Time 3 - Client B issues PUT request
> Time 4 - PUT 'B' succeeds
> Time 5 - The response to the first PUT is generated, reflecting the
> current content which is that of the second PUT, which is not at all
> what the client expects.
>
> Or to make a more interesting example
>
> Time 0 - Client A issues PUT request
> Time 1 - Put succeeds
> Time 3 - Client B issues DELETE request
> Time 4 - DELETE succeeds
> Time 5 - The response to the first PUT is generated, but the resource
> is now gone...
>
> The other approach is using 204/201 with a cache validator. But this do
> not allow the client access to the resulting resource after it's
> request when this race occurs.
>
> Time 0 - Client A issues PATCH request
> Time 1 - PUT A succeeds, etag "1" returned.
> Time 2 - Client B issues PATCH request
> Time 3 - PUT B succeeds, etag "2" returned.
> Time 4 - Client A issues conditional GET using etag "1", which fails
> it's condition as the resource has been changed. It's now impossible
> for Client A to get the results of it's request to verify how the
> modifications was applied.
>
>
>
> So the need for 209 would be to explicitly disallow this family of race
> conditions, enabling the client access to the modified resource just
> after the completetion of it's own request before any other
> modification.
>
> If 209 can not guarantee this then it's no better than using a
> subsequent GET to fetch the modified resource if needed by the client.
>
>
> Regards
> Henrik

Received on Wednesday, 5 September 2007 21:10:20 UTC