W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

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

From: Rohit Khare <khare@pest.w3.org>
Date: Mon, 11 Dec 95 14:49:16 -0500
Message-Id: <9512111949.AA00372@pest.w3.org>
To: Larry Masinter <masinter@parc.xerox.com>, rafal@jaka.nn.com, mslevine@theory.lcs.mit.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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  

Rohit Khare
Received on Monday, 11 December 1995 11:52:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC