- From: Sanford L. Barr <sbarr@interwoven.com>
- Date: Mon, 23 Feb 1998 16:13:40 -0800
- To: "'Judith Slein'" <slein@wrc.xerox.com>
- Cc: Yaron Goland <yarong@microsoft.com>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
You are correct, the "lock optional" model (discussed below) still suffers from lost updates, and my two letters this morning are cause for confusion. Let me propose a taxonomy of WEBDAV locking models to help our discussion: Here are the three main categories of locking models that the current WEBDAV draft supports: lock always (no "lost updates"): - WEBDAV server requires that a resource is locked before 'PUT' (or any other modifier) can occur. - lock token must be presented for every PUT lock optional (possible "lost updates" - dangerous unless all clients are well behaved): - WEBDAV server allows locks to be taken or not - lock token only needs to be presented for locked resources lock never: - WEBDAV server fails all lock requests (proposed clarification) - lock tokens are never required. "lock always" and "lock never" modes are safe, since clients can always guarantee their understanding of the state of a non-live resource. And as I previously mentioned, "lock optional" is downright dangerous (and I doubt it will be implemented in anything but the most controlled environments). (Up until today, I believed "lock always" was unachieveable with the current spec, hence my alarm at only being only left with the "lock optional" and "lock never" models. This morning, in disbelief that the spec wouldn't enable a "lock always" design, I had the pleasure of discovering that 5.1 and 8.7 read as one would satisfy the requirement.) My last two letters were focusing only on the "lock always" and "lock never" models. And as you aptly point out, in the "lock optional" model, "lost updates" still exist and I still strongly agree that a special section noting the inherent dangers of this model are appropriate. As I revisit it, please disregard my original edit for 4.3 since it ignores the "lock optional" mode. With that in mind, since it's helped clarify my thinking, I'm wondering if we should integrate a locking taxonomy into the implementation note for 4.3. to help clarify both the models and the guarantees? Equally well, If it hasn't already been addressed in the 07 spec, an explicit note about failing lock requests for non-locking servers/ non-lockable resources might be beneficial. -San Sanford L. Barr wrote: >If we require all servers to explicitly fail 'LOCK' requests on >non-lock-enforcable resources, then 'B' will never be under a false >assumption that it's preventing other clients from writing to the resource >and can take appropriate action. > >I'd like to enlist help from the members of this list to flesh out the >following proposal: > >Add text to either 7.12 or 8.7 that states something to the effect of: 'LOCK >requests on non-lock-enforcable resources MUST explicitly fail. For servers >that don't support locking, all LOCK requests MUST fail'. (Either using >'424 - Method Failure', or another code explicitly stating 'Method Not >Supported'). -----Original Message----- From: Judith Slein [SMTP:slein@wrc.xerox.com] Sent: Monday, February 23, 1998 1:11 PM To: S. Barr Cc: Yaron Goland; 'Judith Slein'; w3c-dist-auth@w3.org Subject: Re: "Lost Updates" still persist Now I'm really confused. I thought you were correct in your earlier analysis, that we could not prevent A from overwriting B's changes. At 12:24 PM 2/23/98 PST, S. Barr wrote: >It seems that "lost updates" are already prevented for servers that enforce >locking on specified resources, and we may be able to prevent the scenario >for non-locking servers (or non-lock-enforcable resources) without much >work: > >From 8.7 and 5.1, locking servers can prevent the scenario from occuring >altogether. For these servers every PUT on a locked resource will have to >be accompanied by a valid locktoken which the server can verify and enforce. >In this case, Client A's 'PUT' would never succeed. Every PUT on a locked resource does need a locktoken, but the resource is no longer locked when A does its PUT, so the PUT succeeds. > >For non-locking servers (or the case where the lock on the resource in >question is non-enforcable), the scenario between A & B can only exist if >the server falsely claims that it's locking a resource. (The WEBDAV server >would have had to grant a non-enforcable "lock" to 'B'). It's true that a non-locking server should always fail a lock request. But in the scenario, the server did successfully execute B's lock. The server does enforce B's lock. If A had tried to lock the resource while B held the lock, A would have failed. If A had tried to PUT the resource without the appropriate locktoken while B held the lock, A's PUT would have failed. --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 19:13:46 UTC