- From: Judith Slein <slein@wrc.xerox.com>
- Date: Thu, 19 Feb 1998 08:54:24 PST
- To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
- Cc: "'Yaron Goland'" <yarong@microsoft.com>
If we decide to go the "Implementation Note" route, I would suggest something more like the following for the new text. The idea is to state clearly what the problem is, why the protocol can't solve it, and what clients and servers can do to help the situation. 4.3 Usage Considerations Although the locking mechanisms specified here provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario: Two clients A and B are interested in editing the file 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to do locking. 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 servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before accessing them. Such servers would effectively exclude HTTP 1.0 and HTTP 1.1 clients. 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 Thursday, 19 February 1998 11:50:53 UTC