Re: "Lost Updates" still persist

First, great job on summarizing the locking arguments. 4.3 is succinct and
to the point.

After reviewing the locking scenario between A & B contending for the same
resource, I believe we can even shorten 4.3:

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.

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').

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').

We can then remove the first four paragraphs (setup and scenario between A &
B) from the 4.3 note below.  The remaining paragraphs should remain to
outline 'good behavior' in a non-locking environment.

[a proposed edit]
--
4.3 Usage Considerations

WebDAV servers that support locking can prevent clients from accidentally
overwriting
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.
--

Comments?

-San


-----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 15:23:02 UTC