Re: 'PUT' transaction reconsidered (was Re: two-phase send concerns )

Another major limitation of the PUT (or PATCH) transaction is that the client  
never knows which version of the data is about to be overwritten. This note  
is a heads-up to the list that I and few colleagues are designing (& proving)  
a resource-leasing technique that may be the answer to both the two-phase and  
locking problems of PUT.

An excerpt from the document:

>  	The Web, in its guise as a document publishing
>  	system, has always been envisioned as an editable
>  	medium. To that end, the HTTP standard includes
>  	specification not only of the common GET and POST
>  	methods, but also PUT and DELETE. However, PUT
>  	blindly replaces the old data for a resource with
>  	the contents of the new message -- the client
>  	can never be sure of what data is being
>  	overwritten. This is the "lost-update" problem.
>
>  	First, we can extend HTTP to detect lost-updates:
>  	each PUT request  and reply includes the
>  	Content-Version of the data being modified
>  	(Content-Version is some opaque  identifier, like
>  	an MD5 hash). If the two differ, some update has
>  	been lost.
>
>  	Second, we can prevent  lost-updates through an
>  	HTTP mechanism for preconditiong  actions. We
>  	can send a header that only enables a "conditional
>  	PUT" iff the current Content-Version at the
>  	server's end matches the client's expectations.
>  	However, a particular client may never succeed
>  	at updating the resource, since other processes
>  	may modify the Content-Version before it can post
>  	its update.
>
>  	Third, we can guarantee progress by explictly
>  	granting clients exclusive update privileges for
>  	a fixed time interval. That is, clients may
>  	request leases on resources frm servers, and be
>  	guaranteed a window to return with updates.
>
>  	Fourth, we can plan a fair lease-granting system
>  	that guarantees that each contending process will
>  	indeed receive a lease in finite time. We propose
>  	a new techniques, based on Lamport's Bakery
>  	algorithm, called Auctions, which is specifically
>  	adapted for HTTP.

Basically, you probe (in GET or HEAD) to get a lease; if you do get a lease,  
for the next delta-t seconds, you're entitled to use that lease in a  
Authorization: header (using the LEASE scheme) to execute an exclusive PUT or  
POST or PATCH.

Rohit Khare
khare@w3.org