Re: PATCH Draft

Good point.

Furthermore RFC2616 section 8.1.2.2 advises: "Clients SHOULD NOT  
pipeline requests using non-idempotent methods or non-idempotent  
sequences of methods (see Section 9.1.2)."

And 9.1.2 says: "However, it is possible that a sequence of several  
requests is non-idempotent, even if all of the methods executed in  
that sequence are idempotent. (A sequence is idempotent if a single  
execution of the entire sequence always yields a result that is not  
changed by a reexecution of all, or part, of that sequence.)"

While I am now not certain that "PUT+GET" count as idempotent  
sequence, any sequence containing PATCH has to be regarded as non- 
idempotent. I think.

A request header seems a good way to approach this for PUT and PATCH.  
But is it clear on seeing a 200 response with empty body that the  
server has honored the header? Is a response header needed here as well?

Cheers,

Stefan

Am 28.06.2007 um 22:24 schrieb Jeffrey Mogul:

>
> Cyrus Daboo writes:
>
>     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.
>
> Larry Masinter writes:
>
>     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'?
>
> Initially, I had the same reaction.  But I don't think this is
> reliable w.r.t. the specification (although it might be reliable
> for all existing implementations).
>
> Remember, RFC 2616 section 8.1.2.2 does say "A server MUST send its
> responses to those requests in the same order that the requests were
> received."  However, it does NOT say "A server MUST completely
> process one request on a persistent connection before processing
> any subsequent request on the same connection."
>
> So you could have a situation where the client issues a pipelined
> PUT followed by a GET, but a multithreaded server cleverly decides
> to process the PUT in thread X and to  start processing the GET in
> thread Y before the PUT is done.  So the result from the GET,
> while it gets to the client after the result from the PUT, shows
> the state of the resource before the PUT (or worse, an inconsistent
> state "during" the PUT).
>
> CPU architects (and compiler writers) deal with this same problem
> all the time, now that most memory systems do out-of-order operations.
> The solution in this case is a "memory barrier" (MB) operation, which
> the compiler inserts between any code sequences that have to
> be properly serialized.  Then, in all other cases, the hardware
> is free to reorder memory operations arbitrarily, which can really
> improve performance.
>
> In the case of HTTP, it seems less likely that we would want to
> define a new "MB" method just for this purpose (although maybe
> the DAV people see this problem in other cases) -- in particular,
> in a CPU there's a single "session" between the CPU and memory,
> but in HTTP, persistent connections come and go -- so to define
> an "MB" method that works across connections and over shared
> proxies seems like it would be way too complex.
>
> Which means, I think, that the right way to solve Cyrus's
> problem is probably the one he suggested -- add an optional
> method to the PUT request that causes PUT to return the resulting
> entity.
>
> -Jeff
>

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782

Received on Thursday, 28 June 2007 20:48:13 UTC