- From: Jim Amsden <jamsden@us.ibm.com>
- Date: Thu, 7 Dec 2000 10:01:38 -0500
- To: w3c-dist-auth@w3c.org
I agree with Jim. DAV4J does this too. If you use a tagged-list If header, you'll need to include the parent collection as it is changed by virtue of adding the new member. Well, in my opinion this is perfectly clear :-) Choice #1. This interpretation is the intent of the language in Section 7.5 on RFC 2518: when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection. and If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock. It is possible to specify the lock token using either a no-tag-list or a tagged-list If header. - Jim > Interesting difference in interpretation of RFC2518 :) > > Assume I have a resource /foo that is locked depth infinity by a > lock token > <lt> > > No resource exists at /foo/bar > > A PUT is performed at /foo/bar with a No-tagged-list passing the > lock token > in the IF header. What should the correct response be. From our limited > testing: > > 1) Xythos - 201. The resource /foo is locked and /foo/bar does > not exist. > Thus the lock token is correct for every resource that exists (/foo) and > thus the creation of the file is allowed. > > 2) Mod_dav - 412. (I am assuming this is the rationale). /foo/bar does > NOT exist. The token should be applied to the state of resource > /test/foo. > The resource does not exist, so the token cannot match. Thus it > fails with > 412. > > I could argue this either way. I of course lean toward the 201, but that > just might be because it is the first way I interpreted the spec.
Received on Thursday, 7 December 2000 10:12:38 UTC