RE: [Moderator Action] Questions on Webdav Servers

Kevin,

Thanks for posting your questions!

Kevin Wiggen writes:
> 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??

Good point.  Either choice is equally bad, since its unclear which resource
is causing the problem.  For example, if one chose to return a 423, then it
is unclear whether the 423 is due to the Request-URI being locked, or the
parent being locked.

This is a generic problem with HTTP error reporting -- each error should
give the status code, and the URL with which it's associated.  It should
also be possible to report multiple errors in a single message -- for
example, it might be the case that several simultaneous errors could be
occurring.

Fow now, I recommend using 423 (Locked), although we need to add a new
status code, 4xx (Parent Locked).  Though the language is a big unclear,
this is the intent of the discussion in the second paragraph of section 7.5
of RFC 2518 (which states that 423 Locked should be used).

> 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.

> 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.

If the destination of a COPY/MOVE is locked, and you submit the lock token
of the destination lock in the If header, then the intent of RFC 2518 is
that the destination resource should be locked.  This is stated in the
second paragraph of section 7.7.

> 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....)

Two points.

First, if you want, your server can treat all requests on /foo and /foo/ as
applying to the collection resource /foo/.  The language in the 6th
paragraph of section 5.2 discusses this.  So, if you want, you can have both
/foo and /foo/ apply to the collection resource, returning the
Content-Location header in the response with a value of "/foo/" for requests
on /foo.

> If I create one with a trailing slash, can I only do a MKCOL later?

Hmm, it seems reasonable to me to allow PUT as well -- it would create a
collection and set its body, even though it has no children.

> 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.

In this case, I think the MKCOL should be refused.

- Jim

Received on Monday, 26 July 1999 14:02:08 UTC