- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 20 Sep 2001 10:46:20 -0400
- To: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault [mailto:lisa@xythos.com] 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 Actually, it's the other way round, i.e.: IF (token1 token2) (token3 token4) is if (token1 AND token2) OR (token3 AND token4) 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) Yes, you tag lists, not tokens (but you need to swap AND and OR, i.e. --> if (href1 has locktoken1 AND href1 has etag1) OR (href2 has locktoken2 AND 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? This has been debated in a thread a while back, and as I recall, there was weak consensus around saying that you can associate the locktoken in the IF header with any URL that identifies a resource that is affected by the lock, not just the URL to which the lock was applied. Which means that: PUT C/R If: <C/R> (<locktoken-from-C>) And this? PUT C/R If: (<locktoken-from-C>) would succeed. Cheers, Geoff
Received on Thursday, 20 September 2001 10:47:28 UTC