RE: PUT and Lock

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