Re: PATCH Draft

Stefan Eissing wrote:
> 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.

PATCH is neither safe or idempotent.  It is possible to imagine that
certain specific sequences containing PATCH could be considered to be
idempotent but I think such cases are going to be the exception rather
than the rule.

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

Hmm.. I would almost be more inclined to use a new 2xx response code
than a new response header.  E.g. something like "209 Content Included".
The code would indicate a successful request and that the payload
contains a representation of the modified resource.  The spec can
require the use of the new code iff the server decides to return the
modified resource.

- James

> 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, 5 July 2007 19:39:55 UTC