Subject: If: header and "parent" resource checking

From: Greg Stein <[email-masked]>
Date: Sat, 27 May 2000 12:56:06 -0700 (PDT)

I'm going through mod_dav right now and refining/verifying what resources
it checks during If: header processing. I'm taking a particular approach
that I want to bounce off the group to see if this makes sense and is
"proper".

Specifically, it revolves around whether we need to check the "parent"
resource to see if it is locked and the If: header contains those locks.
Say you're doing a MKCOL. The spec states that you must satisfy the locks
held on the parent resource. The following cases are a bit less obvious:

*) when using LOCK to create a locknull resource, this effectively creates
   a new resource in the parent collection.
   ==> parent resource should be checked

*) when using UNLOCK on a locknull, this effectively deletes a resource
   from the parent collection
   ==> parent resource should be checked

*) using MOVE on a resource: this removes the resource from the parent
   ==> parent resource should be checked

*) MOVE and COPY create resources at the Destination
   ==> parent resource of the Destination should be checked

*) MKCOL on a null resource
   ==> parent resource should be checked

*) MKCOL on a locknull resource does not add any resources to the parent
   collection
   ==> parent resource SHOULD NOT be checked
   (the [locknull] resource itself will be checked, however)

*) PUT operates similar to MKCOL w.r.t. locknull resources

Note that this can be an interoperability item. If one server enforces
that conditions be met for the parent, but another doesn't, then a client
(that doesn't provide parent conditions) could fail.

Cheers,
-g

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

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 27 May 2000 23:27:25 -0400 (EDT)

What Greg proposes is consistent with what is stated in 2518.

But I believe it is also consistent to say that a lock null resource
is not treated as a real member of a collection (just as there are
various other ways where it doesn't act like a real resource).

This is compatible with section 7.5 of 2518, which states that:

   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.

i.e. it says nothing about the creation of "lock-null" resources via
the LOCK request.

Having a LOCK request not interact with locks on a parent collection
ensures that a LOCK request has consistent behavior wrt a write-locked
parent collection, whether or not a resource currently exists at the
LOCK request-URL.  It also ensures you do not get the bizarre behavior
where the first shared lock on a null resource requires the lock token
for a locked parent collection, while all subsequent shared locks do not.

So I would defer the need for a lock token for the collection lock
until the PUT or MKCOL is made.  Similarly, I believe an UNLOCK should
*never* require a lock token other than the one being unlocked.

With this premise, I'd make the following changes to Greg's proposal:

   From: Greg Stein <[email-masked]>

I want no parent resource check for this.

I want no parent resource check for this.

I agree.

I agree.

I agree.

I want the lock token to be required.

I agree that PUT should operate similar to MKCOL wrt locknull resources
(but I would want a lock token to be required).

Cheers,
Geoff

---

From: Greg Stein <[email-masked]>
Date: Sun, 28 May 2000 03:41:01 -0700 (PDT)

> various other ways where it doesn't act like a real resource).

I see no rationale to create more differences :-)

> i.e. it says nothing about the creation of "lock-null" resources via

I think that you are being too literal in your reading [in order to
support your position]. Note that the text in question does not mention
MKCOL or BIND, yet we expect the client to provide a locktoken for the
parent on those methods.

In other words, I am reading S7.5 as a "general description of behavior"
rather than a literal/explicit description. As a result, the creation of
ANY internal member, by ANY means, should (IMO) require the client to
provide locktokens for the [write-locked] parent collection.

> for a locked parent collection, while all subsequent shared locks do not.

You can't issue two MKCOL methods for the same resource, so I believe
there is precedent for the different behavior.

Using lock to create a locknull resource is a state-changing operation of
the target resource. It seems quite reasonable to have methods operate
differently, based on the different states of that resource.

Another counter-example for you:

    Collection <locktoken A, depth=0>
      (no internal members)

The client issues a PUT to create "Resource" within Collection. Since this
is the first PUT (thusly creating the internal member), locktoken A must
be provided. Now the client issues a second PUT. But wait! The locktoken
DOES NOT need to be provided.

Therefore: I submit that your argument does not hold, and that the
behavior that I detailed w.r.t. locknull resources is "correct."

I'm still quite open to discussion, of course. I don't want to create
incompatibilities in behavior.

Cheers,
-g

p.s. of course, IIS5 doesn't even allow collection locks, so clients can
simply be screwed anyhow :-)

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sun, 28 May 2000 14:13:01 -0400 (EDT)

I believe a "lock-null" resource is best treated as a convenient
fiction maintained in order to make it easy to query for the existence
of locks.

In particular, according to section 7.4 of 2518, a lock null resource
acts the same as a null resource for all methods except for PROPFIND
and UNLOCK.  A DELETE on a lock null resource MUST fail, a MOVE on a
lock null resource MUST fail, a COPY on a lock null resource MUST
fail, etc.

The reason I am particularly concerned that the creation of a lock NOT
be treated as a modification of the state of the parent collection is
to ensure that effect of creating a lock-null resource is treated
consistently in the versioning and the locking protocols.

In the versioning protocol, the creation of a lock-null resource cannot
be a modification to the state of the collection containing it, because
if the collection were versioned, this would then require a new revision
of that collection in order to hold the "new resource".  But then this
lock-null resource could never be removed from this collection revision,
because revisions are immutable.

On the other hand, if the addition of a lock is not considered a modification
to the state of a collection, but rather the modification occurs at the
first PUT, then all is well ... no "immutable" locks end up being captured.
In this model, a lock is not a modification to the state of a resource
(either the resource itself, or the collection containing the lock), but
rather "metadata" that controls interactions with the state of the resource.

In versioning, this is also how "labels" are handled, i.e. as metadata on
a resource that does not modify the state of the resource.

I'd *very* much like the versioning protocol and the locking protocol to
be consistent as to whether the creation of a lock-null resource modifies the
state of the collection containing them.  Since I don't see that the
versioning protocol has a choice in this regard, I'd like to see the locking
protocol handle it the same way, unless there is some serious problem that
arises from doing so.

So I guess what I'd like to hear is why it is important for the addition
of a lock-null resource to be treated as a modification to the state of
the collection containing it.

Cheers,
Geoff

   Date: Sun, 28 May 2000 03:41:01 -0700 (PDT)
   From: Greg Stein <[email-masked]>

   Cheers,
   -g