RE: PATCH Draft

I'm having to dust off some very old memories but it is my recollection that HTTP does not guarantee end-to-end pipelining order.



Client ---> Proxy ---> Server



If the Client pipelines a PATCH and a GET to the Proxy it was my understanding that the proxy was free to handle those two requests anyway it likes including sending the GET before the PATCH or sending them on two separate connections in parallel or what have you. While it is true that the proxy has to return the results in the order the client requested this does not guarantee that the methods were processed in the order they were submitted. So the client could get a GET result that was executed before the PATCH. And with all the well known problems with dates the client can't just compare the dates on the two responses and so re-create the 'true' ordering.



      Yaron



> -----Original Message-----

> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]

> On Behalf Of Larry Masinter

> Sent: Thursday, June 28, 2007 12:06 PM

> To: 'Cyrus Daboo'; 'James M Snell'; 'Julian Reschke'

> Cc: 'Henrik Nordstrom'; 'Lisa Dusseault'; ietf-http-wg@w3.org

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

>