More questions on the IF header

Geoff answered my previous question on the IF header and I have to agree
with him.  In my words, if you see two IF header tokens in the same parens
() you can OR them; otherwise you have to AND them.  So:
IF: (<locktoken1> [etag1])
--> if locktoken1 or etag1 matches the resourceURI

IF: (<locktoken1>) ([etag1])
--> if locktoken1 AND etag1 matches the resourceURI

When tagged tokens appear, it seems you can't combine two tokens with
different tags in the same parens.  So:
IF: <href1> (<locktoken1> [etag1]) <href2> (<locktoken2> [etag2])
--> if (href1 has locktoken1 OR href1 has etag1) AND (href2 has locktoken2
OR href2 has etag2)

Now I have a new question...

We know that when a collection with URL 'C/' is locked with depth infinity,
and a resource R is inside it or added to it, the resource R is somehow
'included' in the depth infinity lock.  Does that mean that the locktoken
created for the lock on C applies to R?  Or must the locktoken always be
associated with the exact URL for which it was created?

The language from section 9.4 is "If
   the state of the resource to which the header is applied does not
   match any of the specified state lists then the request MUST fail
   with a 412 (Precondition Failed).  "

So my question can be reworded as, does a child resource "match" the lock
token from a infinite-depth lock on a parent resource?

We know this will work, because it applies the lock token to the exact
resource for which it was created:
  PUT C/R
  If: <C/> (<locktoken-from-C>)

But must this succeed, or must it fail because the locktoken from C is
tagged to the "wrong" resource?
  PUT C/R
  If: <C/R> (<locktoken-from-C>)

And this?
  PUT C/R
  If: (<locktoken-from-C>)

lisa

Received on Wednesday, 19 September 2001 20:34:28 UTC