- From: Judith Slein <slein@wrc.xerox.com>
- Date: Tue, 24 Feb 1998 11:40:55 PST
- To: sbarr@interwoven.com
- Cc: "'Yaron Goland'" <yarong@microsoft.com>, <w3c-dist-auth@w3.org>
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