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

Section 7 of the WBOW vAlpha2
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html)
point to
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html which
explains the reasoning.

		Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Sat, July 24, 1999 8:39 PM
> To: ejw@ics.uci.edu
> Cc: w3c-dist-auth@w3.org
> Subject: 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 Friday, 6 August 1999 13:17:10 UTC