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

See reply below in <jra> tags...





Jim Whitehead <ejw@ics.uci.edu> on 07/24/99 09:29:20 PM

To:   WebDAV WG <w3c-dist-auth@w3.org>
cc:

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




Accidentally caught by the spam filter.  A request has been made to add this
email address to the accept2 list for this mailing list.

- Jim

-----Original Message-----
From: Kevin Wiggen [mailto:wiggs@xythos.com]
Sent: Friday, July 23, 1999 3:08 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Questions on Webdav Servers


The following are a few more questions I have.

1)  When a PUT/MKCOL/DELETE/MOVE/COPY occur and the PARENT is locked, what
should the correct response be??  Should it be 423 locked?  412
pre-condition failed.  And is it different if its a PUT/MKCOL/DELETE vrs a
MOVE/COPY??
<jra>
Locking a collection is intended to protect the collection from change by users
not owning the lock. Changing a collection means changing its members. This
implies that any method that would add or remove members from the collection
will require the lock token. This includes PUT, MKCOL, DELETE, MOVE, and COPY
(if the locked collection is in the destination parent). All other methods are
allowed.
</jra>

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"???
<jra>
Clients are free to change this default.
</jra>

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.
<jra>
After a copy or move, the destination resource is not the same resource. So it
doesn't make sense to retain the lock.
</jra>

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....)
<jra>
A NULL resource isn't either a collection or resource, its a NULL resource (an
ugly special case resulting from WebDAV not having transaction semantics). So
you should be able to do a PUT or MKCOL on a NULL resource to convert it into a
real resource.

I understand what you mean by the special cases. Its bad enough to have to
maintain such code, but even worse for users to remember all the special cases.
Again, client applications can and should hide these semantics. For example, a
client could have a "create resource" method that locks a non-existant resource
and then does a PUT. The user doesn't ever have to know about the NULL resource
used to "reserve" the name.
</jra>

Thanks,
Kevin

Received on Sunday, 25 July 1999 10:25:07 UTC