Re: PATCH Draft

Hi James,

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

>> 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