W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Re: PATCH Draft

From: Cyrus Daboo <cyrus@daboo.name>
Date: Thu, 28 Jun 2007 14:59:19 -0400
To: James M Snell <jasnell@gmail.com>, Julian Reschke <julian.reschke@gmx.de>
cc: LMM@acm.org, "'Henrik Nordstrom'" <henrik@henriknordstrom.net>, "'Lisa Dusseault'" <ldusseault@commerce.net>, ietf-http-wg@w3.org
Message-ID: <D43F5B002C74B52677A3C34A@caldav.corp.apple.com>

Hi James,

--On June 28, 2007 10:47:59 AM -0700 James M Snell <jasnell@gmail.com> 

>> In the general case PATCH either fails with 4xx (Conflict) or succeeds.
>> In the latter case, a client can always send a subsequent GET.
> The only challenge with this is that the whole point of returning the
> entity in the response is to verify that the resource was patched
> successfully.  If the resource is modified between the time the PATCH
> response is received and a subsequent GET is issued, then verifying the
> result becomes problematic.  Using Etags we can obviously detect the
> subsequent change, but it's harder to verify that our specific change
> was applied correctly.  For byte/character based deltas, this is not so
> much of a problem.  For structural deltas it can be a significant problem.

Yes - indeed I have run into a similar problem with CalDAV. In that case 
the server is a gateway to another calendar system and has to modify data 
that is PUT by a CalDAV client. Because of all the well-known issues with 
ETags on PUT, the client is currently forced to immediately turn around a 
do a GET to get the server-modified data back. It would be nice if there 
were an HTTP request header for PUT that told the server to return the 
actual stored entity (if a change actually occurred) with its corresponding 
ETag. That would avoid the need for the extra roundtrip.

Cyrus Daboo
Received on Thursday, 28 June 2007 18:59:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC