- 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
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
Received on Thursday, 28 June 2007 18:59:53 UTC