- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 18 Jul 2001 10:09:02 -0400
- To: WebDAV <w3c-dist-auth@w3.org>
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] As an implementor of server and client software using WebDAV, I would have gladly skipped the mechanisms known as lock-null resources. As Geoff pointed out in this thread, there are alternatives for clients to live without them (although not quite as comfortable). It's probably worth noting that a client gains little or nothing from the use of lock-null resources. In the common case, the user has selected either "Open" or "New" from some user interface. In the Open case, the user is expecting an error if the resource does not exist, so having LOCK return 404 actually makes the client protocol simpler. In the New case, the user is expecting an error if the resource already exists, so a PUT/If-None-Match can be used to determine if the resource does not exist, followed by a LOCK to verify the resource can be write locked. In case the user interface does not distinguish between Open and New, the client just follows the LOCK call with a: if status is 404 then PUT/If-None-Match # ignore status from this request LOCK and otherwise uses the exact same code it would have used if lock null resources were supported. (Note: the "PUT" would whatever is the right call to create a null resource of the right type, e.g. MKCOL for collections, MKACTIVITY for activities, or whatever). But the choice to include lock-null has been made in the past and I see more trouble with abandoning it, than keeping it. Every implementation I've seen (and that might be too few) implements lock-null correctly. You need to look at the Microsoft IIS implementation. When a LOCK is applied to an unmapped URI, it just automatically preceded the LOCK with a PUT with a 0 length body. The result is a regular locked resource, not a lock null resource. In particular, MKCOL will fail on that resource, and when you remove the lock, you still have the 0 length resource (i.e. it doesn't disappear, as a lock null resource is required to do). Note: Our implementation is likely to act the same way, probably for the same reasons as Microsoft, i.e. we support multiple protocols accessing our repository, and none of the other protocols have anything remotely resembling lock null resources. Apart from certain software from Seattle based companies: their server has an incomplete implementation, which works only for ordinary resources. It works good enough for the Seattle client software which uses this feature. Now, if WebDAV removes lock-null, every server implementor would have to support it anyway, because 90% of the users use those Seattle clients. I therefore see nothing to gain on the server side by abandoning lock-null. Having your server support the behavior expected by IIS is easy, just automatically create a 0-length resource. It is real lock-null behavior (which is not implemented by IIS) which is the problem. In the revised protocol, we can warn clients about the various ways that existing servers deal with a LOCK applied to an unmapped URI, but could increase interoperability in the future by stating that a LOCK to an unmapped URI SHOULD return a 404. On the client side, lock-null is a comfortable thing to use. So there is nothing to gain either. If you care about interoperability, it is not comfortable to use because it is not implemented uniformly, so you have to special case around the alternative implementations. The client code will be simpler if it just doesn't use lock null resources at all. So, I'd say: let's embrace and extend lock-null resources. Lock-null resources are very unlikely to be embraced by implementors who must care about multiple protocols accessing their repositories (and commercial vendors are almost all in that situation). Any attempt to embrace (much less extend) lock-null resources will result in interoperability problems. If they were the only good way to provide a key client use case, I'd be willing to live with the interoperability problems, but since the lock-null use cases are easily supported without lock-null resources, I see no reason to persist (much less, increase) these problems. Cheers, Geoff
Received on Wednesday, 18 July 2001 10:01:33 UTC