W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001


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:


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
   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

   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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:22 UTC