RE: "Lost Updates" still persist

Sanford,

On Thursday, February 12, 1998 3:04 PM, Sanford L. Barr 
[SMTP:sbarr@interwoven.com] wrote:
>
> I claim if you don't enforce locking to be adhered to by all clients, 
then
> "Lost Updates" for those clients who _do_ lock are still possible.
>

I think we are all in agreement that the scenario you outline is possible 
given the way locking is defined in the current specification. What we 
differ over is the perception of how significant this is.

To start with, let me point out that the same scenario you outline is also 
possible using shared locks.  The resolution to overwrite conflicts using 
shared locking is to employ some form of floor control which is negotiated 
out-of-band of the WebDAV protocol, for example, talking on the phone to 
see who can make changes next.  While your scenario differs from shared 
locks in that there is no way to discover that someone else is editing 
(i.e., in your scenario, lock discovery isn't possible), I suspect the 
resolution to overwrite conflicts will be the same: use of out-of-band 
floor control negotiation among collaborators.

Technical solutions to this problem are not obvious.  If you require a lock 
token to be submitted for PUT, this is difficult to enforce against 
downlevel HTTP servers which will ignore the Lock-Token header for PUT, 
seemingly behaving correctly (because they ignore headers they don't 
understand), but really not.  If you insist that clients working against a 
DAV server use locking, how should downlevel HTTP/1.1 clients which support 
PUT be handled?  After all, they are using PUT the way it is specified in 
the HTTP/1.1 spec.

Yaron's solution of requiring all clients which use PUT to submit the 
entity tag of the pre-edit resource with an If-Match header when submitting 
a PUT request would address the problem, but would not help downlevel 
PUT-capable clients which do not support this capability.

Another approach is to provide a "write-only-if-locked" access control 
type, which would make the resource writeable only if it is locked.  This 
would exclude downlevel PUT-capable clients, without having to mandate a 
use order between methods, a dubious proposition for a stateless protocol 
like HTTP.

- Jim

Received on Friday, 13 February 1998 19:09:07 UTC