- From: S. Barr <sbarr@interwoven.com>
- Date: Mon, 23 Feb 1998 09:57:26 -0800
- To: "Yaron Goland" <yarong@microsoft.com>, "'Judith Slein'" <slein@wrc.xerox.com>, <w3c-dist-auth@w3.org>
As it turns out, the issue I was originally addressing was the lack of server enforcability of locks. As I misread, webdav didn't enable servers to enforce locking if they desired. (My first time through the spec let me to believe "PUT" never took a locktoken, hence wasn't enforcable, forcing clients to take on all lock coordination responsibilities). After a good weeks vacation, I see that not only do I stand corrected, but I extend my apologies to the group and my thanks for your good humor. Section 5.1 combined with section 8.7 address exactly what I was looking for in server lock enforcability. Just to help future poor souls like myself, might we explicitly define lock interaction for each method affected by locking in that method's section? (a small 'Locking Considerations:' note at the end of each method definition listed in 5.1?) Thanks, -San > For example, Program A, used by user A, takes out a write lock on a > resource. Program A then makes a number of PUT requests on the > locked resource. All the requests contain a Lock-Token request > header that includes the write lock token. Program B, also run by > User A, then proceeds to perform a PUT to the locked resource. > However, program B was not aware of the existence of the lock and so > does not include the appropriate Lock-Token request header. The > method is rejected even though principal A is authorized to perform > the PUT. Program B can, if it so chooses, now perform lock > discovery and obtain the lock token. Note that programs A and B can > perform GETs without using the Lock-Token header because the ability > to perform a GET is not affected by a write lock. -----Original Message----- From: Yaron Goland <yarong@microsoft.com> To: 'Judith Slein' <slein@wrc.xerox.com>; 'w3c-dist-auth@w3.org' <w3c-dist-auth@w3.org> Date: Sunday, February 22, 1998 10:54 PM Subject: RE: "Lost Updates" still persist >Amen. > Yaron > >> -----Original Message----- >> From: Judith Slein [SMTP:slein@wrc.xerox.com] >> Sent: Thursday, February 19, 1998 8:54 AM >> To: 'w3c-dist-auth@w3.org' >> Cc: Yaron Goland >> Subject: RE: "Lost Updates" still persist >> >> 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 Monday, 23 February 1998 12:55:44 UTC