Re: If: header and "parent" resource checking

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 <gstein@lyra.org>


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

I want no parent resource check for this.

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

I want no parent resource check for this.

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

I agree.

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

I agree.

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

I agree.

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

I want the lock token to be required.

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

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

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

Received on Saturday, 27 May 2000 23:27:41 UTC