W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2000

RE: PUT and Lock

From: Jim Amsden <jamsden@us.ibm.com>
Date: Thu, 7 Dec 2000 10:01:38 -0500
To: w3c-dist-auth@w3c.org
Message-ID: <OF0D3F98E5.2A160049-ON852569AE.00526E75@raleigh.ibm.com>
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

   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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:22 UTC