W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: PATCH Draft

From: James M Snell <jasnell@gmail.com>
Date: Thu, 05 Jul 2007 12:39:46 -0700
Message-ID: <468D4902.3020105@gmail.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
CC: Jeffrey Mogul <Jeff.Mogul@hp.com>, Larry Masinter <LMM@acm.org>, 'Cyrus Daboo' <cyrus@daboo.name>, 'Julian Reschke' <julian.reschke@gmx.de>, 'Henrik Nordstrom' <henrik@henriknordstrom.net>, 'Lisa Dusseault' <ldusseault@commerce.net>, ietf-http-wg@w3.org

Stefan Eissing wrote:
> Good point.
> Furthermore RFC2616 section 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 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC