- From: Judith Slein <slein@wrc.xerox.com>
- Date: Mon, 23 Feb 1998 13:10:51 PST
- To: "S. Barr" <sbarr@interwoven.com>
- Cc: "Yaron Goland" <yarong@microsoft.com>, "'Judith Slein'" <slein@wrc.xerox.com>, <w3c-dist-auth@w3.org>
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 16:05:53 UTC