Problem with cond_put_corrupt_token test

[John Meissen]

It's perhaps a bit unfortunate that they overloaded the "If:" header 
this way, because it can lead to some confusion.

There are two separate conditions that must be satisified, both
involving the "If:" header.

The first is the evaluation of the header itself. This determines
whether the operation proceeds at all and is independent of whether
or not the resource itself is actually locked. This is simply a true/false
test. This is a global test that applies to any method, even those
which are otherwise unaffected by locks.

The second is whether the token for a locked resource is included in
the "If:" header. So once the request passes the "If:" evaluation it
still has to determine that the requested resource is locked and
whether the token is included in the "If:" header.

So yes, it should evaluate the condition to true, but should then
fail because the correct token for the lock isn't in the header.

john-

> Hi!
> 
> I'm currently working in my servers class 2 compliance. The test case
> "cond_put_corrupt_token" looks broken to me. It fails with the message
> "(conditional PUT with invalid lock-token should fail: 201 Created)".
> 
> I examined the If header, which looks like this:
> 
> If: (<opaquelocktoken:bed586e3-1876-3f16-b0c9-bccbd0c53947x>) (Not
> <DAV:no-lock>)
> 
> The first condition is the correct lock token, appended by an 'x' and
> therefore a broken lock token. However, the second condition is negated,
> therefore the condition list is overall evaluated to TRUE.
> 
> The test case basically reflects the example from RFC4918 section 10.4.8
> (Example - Causing a Condition to Always Evaluate to True).
> 
> Am I misslead or is the test case broken?
> 
> TIA for any hint,
> cheers,
> Toby
> --
> Mit freundlichen Gr=C3=BC=C3=9Fen / Med vennlig hilsen / With kind regards
> 
> Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer
> 
> ts at ez.no | eZ Systems AS | ez.no