Re: FW: [Moderator Action] Questions on Webdav Servers

   From: Kevin Wiggen [mailto:wiggs@xythos.com]

   The following are a few more questions I have.

   ...

   3)  MOVE/COPY to a destination that is locked.  8.10.5 states "... a
   successful DELETE of a resource MUST cause all of its locks to be removed."
   and 8.8.4 states that overwrite set to T will do a DELETE....  Then will the
   LOCK on the destination be lost??  This seems wrong to me.  If the
   destination is LOCKED, then after a MOVE/COPY which might delete the
   resource, I would assume the resource is still locked.

I believe that the complexity here is due to the decision to have a
WebDAV lock be *both* a resource state lock (which means the state of
the resource is locked no matter what URL you use to access it)
*and* a URL lock (which means that you have a lock on whatever might
appear at that URL).

This was done for some very good reasons, since you need both kinds
of locks to ensure that "when you have the lock, only you can change
what is at that URL".

Unfortunately, the expected behavior of those two kinds of locks is
different under MOVE and DELETE, and the current WebDAV semantics ends
up with (is forced into) a compromise semantics that produces
counterintuitive behavior from either perspective.

In particular, one would expect a URL lock to be unaffected by a MOVE
or a DELETE.  If you've got a URL locked, you should be able to move
anything to it or from it (or even delete it, resulting in a locked
null resource).  This I think is the perspective Kevin was taking.

But a resource state lock acts very differently.  If you delete a
resource, the resource state lock should be deleted as well (no state
left to lock).  This is what WebDAV says.  But if you MOVE a resource,
you'd expect the resource state lock to remain in effect.  But here
WebDAV goes with the URL lock semantics and says that a MOVE deletes
the lock.

Personally, I can live with most of this except for the losing of the
lock on the move.  Can someone point me at something in the archives
that explains this decision?  I didn't find it in Yaron's WBOW.

   4)  I assume that a null resource can be created via a URL with a trailing
   slash and one without.  If I create one with a trailing slash, can I only do
   a MKCOL later?  If no trailing slash is sent, the server probably needs to
   assume that the client might have just not sent the slash and allow a MKCOL
   or a PUT.  I think the spec should state that a NULL RESOURCE can be created
   with a trailing slash or not, AND any NULL RESOURCE can take a MKCOL or PUT.
   (You already messed up some of the beauty of my server with Null Resources,
   I would hate to put even more if statements in to handle the above....)

I agree with Kevin.  

Note: These kinds of questions would not arise if
WebDAV would just state that /foo/x/ and /foo/x always map to
the same resource (JimW and I periodically go round on this
one :-).  Even Windows and Unix agree that this is
the sensible approach.

Cheers,
Geoff

Received on Saturday, 24 July 1999 23:39:16 UTC