- 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