- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Fri, 13 Feb 1998 15:00:25 -0800
- To: "'WEBDAV WG'" <w3c-dist-auth@w3.org>
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