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

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Fri, 6 Aug 1999 10:15:09 -0700

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:[email-masked]]
> Sent: Sat, July 24, 1999 8:39 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: FW: [Moderator Action] Questions on Webdav Servers
> 
> 
> 
>    From: Kevin Wiggen [mailto:[email-masked]]
> 
>    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
>

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Aug 1999 14:15:42 -0400

(I'm replying to this rather late, so I'll do some excessive quoting so people
can get the context.)

Jim Whitehead wrote:

> > 2)  Section 9.6 "...If the Overwrite Header is not included in a COPY/MOVE
> > request then the resource MUST treat the request as if it had an overwrite
> > header of value 'T'".  This seems backwards to me (in fact I had it coded
> > the otherway until yesterday), since the overwrite will do a DELETE, is it
> > not safer to assume a header of "F"???
>
> Well, I'll note that you brought this up previously:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0053.html
>
> And it has been noted on the issues list (issue:
> OVERWRITE_DELETE_TOO_STRONG):
> http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html
>
> I'm certainly willing to see this change as we move from Proposed to Draft
> Standard.  For now, I'd expect user agents to protect users from
> unexpectedly large effects.

The problem with changing it as the standard moves forward is that we run the
risk that existing clients will probably omit the Overwrite header when they
mean T, and people's COPY/MOVEs will start failing when the servers switch
standards.

I'd suggest it'd be best to leave this alone.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/