Re: If: header and "parent" resource checking

On Sat, 27 May 2000, Geoffrey M. Clemm wrote:
> 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).

I see no rationale to create more differences :-)

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

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.

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

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

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

Received on Sunday, 28 May 2000 06:41:23 UTC