Subject: PUT and Lock

From: "Kevin Wiggen" <[email-masked]>
Date: Wed, 6 Dec 2000 15:01:20 -0800

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.

Thoughts?

Kevin
Xythos

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 6 Dec 2000 17:43:00 -0800

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

---

From: Greg Stein <[email-masked]>
Date: Thu, 7 Dec 2000 21:31:27 -0800

>    fail if the principal does not have a write lock on the collection.

I agree this is true, but I don't see how it supports choice #1. This only
refers to needing to assert the write lock on the collection.

>    /a/b/c then resource /a/b/c will be added to the write lock.

This refers to the state of the locks *after* the resource has been added.

> It is possible to specify the lock token using either a no-tag-list or a

Nope.

An If: header is a *pre* condition. The resource does not exist until after
the PUT method completes. A precondition with a no-tag-list refers to all
URIs involved in the operation. In this case: the Request-URI and the parent
collection. The no-tag-list is asserting a lock token on *both* resources,
the but the Request-URI does not have any locks associated with it (it is a
null resource).

At the time the precondition is evaluated, the assertion fails: the parent
has the lock, but the request-uri does not. Therefore, the precondition
fails, and returns a 412.

>...
> > Assume I have a resource /foo that is locked depth infinity by a
> > lock token <lt>
> >
> > The resource does not exist, so the token cannot match.  Thus it
> > fails with 412.

Your rationale/assumption is correct. :-)

mod_dav operates fine if you pass a tagged-list for the parent collection
and assert the <lt> token.

> > just might be because it is the first way I interpreted the spec.

I'm leaning towards the 412: the precondition test fails because the
assertion of a locktoken on the Request-URI fails because it is a null
resource with no outstanding locks.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: "Kevin Wiggen" <[email-masked]>
Date: Thu, 7 Dec 2000 21:55:49 -0800

Well,

After further testing, IIS has nothing to add to this as it does not allow
for locks on directories :)

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg Stein
Sent: Thursday, December 07, 2000 9:31 PM
To: [email-masked]
Subject: Re: PUT and Lock

Nope.

Cheers,
-g