RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

   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