RE: "Lost Updates" still persist

I like your clarifications and categorization of locking models.  If the 07
rev of the spec isn't frozen yet, maybe the authors could just steal from
your mailnote like this:

4.3 Usage Considerations

The WebDAV locking provisions allow servers to choose any of three
different locking models:

Lock Always:
   - The WEBDAV server requires that a resource be locked before a 'PUT',
or any other operation that might change the resource, can occur.
   - A lock token must be presented for every such operation.

Note that if a server adopts this model, it effectively prevents all HTTP
clients from modifying its resources, since these clients do not understand
locking.

Lock Never:
   - The WEBDAV server fails all lock requests. 
   - Lock tokens are never required.

HTTP 1.1 and WEBDAV clients interacting with such servers can be good
citizens, and avoid overwriting other clients' changes, by using entity
tags in If-Match headers with any requests that would modify resources.

Lock Optional:
   - The WEBDAV server allows locks to be taken or not, at the client's
discretion.
   - A lock token only needs to be presented for locked resources.

This model also relies on well-behaved clients to insure safety from
overwrites.  Unless clients are well-behaved, the following scenario can
occur:

Two clients A and B are interested in editing the file 'index.html'.

Client A doesn't lock the document, but does a GET and begins editing.
Client B does a LOCK, does a GET and begins editing.
Client B finishes editing, does a PUT, then an UNLOCK.
Client A does a PUT, overwriting and losing all of B's changes.

There are several reasons why the WebDAV protocol itself cannot prevent
this situation.  First, it cannot force all clients to use locking because
it must be compatible with HTTP clients that do not comprehend locking.
Second, it cannot require servers to support locking because of the variety
of configuration management systems, some of which rely on reservations and
merging rather than on locking.  Finally, being stateless, it cannot
enforce a sequence of operations like LOCK / GET / PUT / UNLOCK. 

WebDAV clients can be good citizens by using a lock / retrieve / write /
unlock sequence of operations (at least by default) whenever they interact
with a WebDAV server that supports locking.

HTTP 1.1 clients can be good citizens, avoiding overwriting other clients'
changes, by using entity tags in If-Match headers with any requests that
would modify resources. 

Information managers may attempt to prevent overwrites by implementing
client-side procedures requiring locking before accessing WebDAV resources.

--Judy



Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 422-2938

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580

Received on Tuesday, 24 February 1998 14:39:53 UTC