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