Re: Suggestion: PUT if-not-modified-since

    While there is no 'LOCK' operation and I'm reluctant to try to define
    one, I would suggest a if-not-modified-since header on 'PUT'.
    
    This would at least allow you to build a web editor with verifier
    semantics; that is, you would GET the document you want to edit, allow
    the user to edit it, and then do a PUT if-not-modified-since. If
    the document is unchanged from what was originally gotten, the PUT
    would succeed (modulo access control, etc.); however, if the document
    had changed since, the PUT would fail. The user agent would have to
    deal with the situation in some way (e.g., retrieve the document anew,
    compare it against the one that was originally obtained, allow the
    user to merge edits, etc.), but at least you wouldn't have one edit
    stepping on another.
    
    Of course, this is for 1.1 or 1.2 or some such. Opinions?
    
This reminds me of a similar problem faced by designers of highly
scalable multiprocessors.  Simple "test and set" opcodes don't
work very well, because they require some sort of global lock
that has to be held for a few memory cycles (== round-trip times).

The design used in the DEC Alpha architecture (and probably others)
follows a different model, something like "PUT-if-not-modified-since".
The opcodes are called "load locked" and "store conditional".  Basically,
the "lock" set by "load locked" may or may not still be set when the
"store conditional" happens.  If it is set, the store completes OK;
if the lock is gone, the store fails and the software must retry.
These loads and stores are matched by using a magic number, which
resembles an address but does not necessarily have the same properties.
The benefit here is that there is no "hard state" in the locking
mechanism.

I would ask one change: Don't use "if-not-modified-since"!!  This
is evil. (Do I repeat myself?  Very well, I repeat myself.)

Use the cache-validator technique, where the server returns
an opaque value with the GET, and the clients presents it with
the PUT, e.g.,
	Put-validator: <URL>, <validator returned with corresponding GET>
Note that by providing a separate URL in the Put-validator, you
can use this locking mechanism for things besides document-editing.
For example, if the PUT represents a purchase order I am submitting,
the Put-validator may refer to a URL giving the price and specifications
for the product I am buying.

This also allows you to have more than one Put-validator on a PUT
request, so that if the "PUT" depends on the unchanged state of
several different URLs, the protocol can reflect that dependency.
For example, my order may depend on the price of several items
and the current table of postage and handling costs, each of which
may be recorded in a different URL.

This has some inevitable implications for caching policy.  For
example, does it make sense to allow a PUT to depend on a URL
that the server has declared to be non-cachable?  My intuition
is "no", but I haven't thought this through.  (If this is correct,
then a browser could warn a user that something "unreliable" has been
requested.)

-Jeff

Received on Tuesday, 5 September 1995 16:11:50 UTC