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

As explained in http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0398.html we in Web3S land definitely have a need for 209 without the race condition guarantee.

I'm also unclear on a real world scenario where a client would apply the PATCH and then as a matter of necessity need to do an immediate GET that is guaranteed to return exactly the state of the resource as it existed after the PATCH. That sounds more to me like versioning than a normal HTTP method.

So my comments would then be twofold:

#1 - I don't believe that 209 with race condition protection is actually necessary. Although I could easily be convinced that I'm wrong if someone has a killer use case.

#2 - We absolutely need the ability to return a 209 without race condition guarantees. So if 209 is going to be defined with a race condition prevention requirement then we can't use 209 and will need to do something else.

So at this point the question for the group goes something like: We in Web3S land need a 209 equivalent without race condition protection. So should we:

        A) If someone comes up with a killer use case for why 209 needs race condition protection then we can come up with a switch that indicates if the 209 had race condition protection or not?

        B) We should declare the race condition protection use case and the non-race condition protection use case as mutually exclusive and introduce different solutions?

Personally I'm less scared of introducing new HTTP headers than I am of introducing new HTTP response codes (it's a scarcity issue). And we will need to ship something very soon. So my guess is that in the medium term we are going to introduce our own request header and our own response header to be used with 200 to handle our immediate needs. If the PATCH spec ends up introducing a version of 209 that meets our requirements then we'll switch over to that.

        Just my two cents,

                Yaron


> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, September 06, 2007 12:50 AM
> To: Henrik Nordstrom
> Cc: Yaron Goland; James M Snell; HTTP Working Group
> Subject: Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]
>
> Henrik Nordstrom wrote:
> > On ons, 2007-09-05 at 14:09 -0700, Yaron Goland wrote:
> >> 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?
> >
> > From what I understand it's the motivation for the 209 response code
> in
> > PATCH, allowing the client to request the patched resource so that it
> > can verify that the patch was applied like expected.
> >
> > If the client can not trust that the 209 response to PATCH is infact
> the
> > resource after applying the patch then there is not much point in
> > supporting 209 for PATCH, and it can just as well be specified that
> the
> > client should GET the resource if it needs to verify..
>
> Right.
>
> The only reason for 209 IMHO is to avoid the potential race condition.
> If that's not guaranteed, there's no point in having it in the first
> place.
>
> Best regards, Julian

Received on Thursday, 6 September 2007 21:47:19 UTC