Re: PATCH Draft

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

Received on Thursday, 28 June 2007 20:24:42 UTC