RE: PATCH Draft

What's the difference between a PUT that includes a header that says
"return the body" and a pipelined GET? Why is the pipelined
GET an 'extra round trip'?

Larry


-----Original Message-----
From: Cyrus Daboo [mailto:cyrus@daboo.name] 
Sent: Thursday, June 28, 2007 11:59 AM
To: James M Snell; Julian Reschke
Cc: LMM@acm.org; 'Henrik Nordstrom'; 'Lisa Dusseault'; ietf-http-wg@w3.org
Subject: 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

Received on Thursday, 28 June 2007 19:07:24 UTC