- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Wed, 18 Apr 2001 13:51:08 -0700
- To: "WebDAV WG" <w3c-dist-auth@w3.org>
This issue was originally raised by Sanford Barr: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0186.html The description of the issue is: Is there a need for a PUTL (put which succeeds only if the resource is locked) method to avoid certain classes of overwrite conflicts, or a need to restrict the behavior of PUT on WebDAV servers to only accept writes if the resource is locked? Additional background rationale is provided in Section 6.7 ("Usage Considerations") of RFC 2518: Two clients A and B are interested in editing the resource ' index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking. Client A doesn't lock the document, but does a GET and begins editing. Client B does LOCK, performs a GET and begins editing. Client B finishes editing, performs a PUT, then an UNLOCK. Client A performs 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 repository implementations, 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 modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources. 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. - Jim
Received on Wednesday, 18 April 2001 16:52:43 UTC