- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 06 Sep 2007 09:50:24 +0200
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- CC: Yaron Goland <yarong@microsoft.com>, James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 07:51:49 UTC