RE: Behavior of PUT on unlocked resource with invalid IF header . ..

<<
   From: Jason Crawford [mailto:ccjason@us.ibm.com]

   My opinion is that...

   The spec should not use the IF header for token presentation to the
   server.  The IF header should only be used for client initiated
   assertion checking.  The current use of IF for dual purposes just
   causes confusion (like I think your note indicates) and impedes our
   ability to potentially extend it later.  We should transition to
   some other header for token presentation to the server.  Or perhaps
   I just misunderstand the IF header and someone needs to clearly
   define it.  :-)

Jason: I don't see your concern here.  The semantics of the If header
is quite clearly defined in 2518, and says that if none of the
state lists that apply to a resource match, then the request must
fail with a 412.  Although as indicated in a previous message, the
"applies to a resource" is not well defined for no-tagged state lists,
this is a general problem with the If header, and not a particular
problem for lock tokens.
>>
If that were all it said, it would be much improved, but it also says that
we use the IF header for token presentation in section 7.6:

   In order to prevent these collisions a lock token MUST be submitted
   by an authorized principal in the If header for all locked resources
   that a method may interact with or the method MUST fail.

And it says similar things other places in the spec.

But nowhere is it defined what "submitted" means.    And what if all the
tokens necessary are included in the IF header, but only one of them
happens to be on the proper URI?   Since one matches the IF criteria, so we
consider the tokens to be duly sumbitted even if they guessed the wrong URL
for most of the tokens.    If you use a 'not' construct, can it be
considered to be submitted?  What if we want to extend the spec to add more
sophisticated boolean logic support to the if header to test
pre-conditions?  Then what does it mean to use the if header to submit a
token?

There is too much behavior overloaded on the IF header.  Let's let the IF
header do what you mentioned and use another means for submitting lock
tokens to assert our ownership of locks.

J.

Received on Thursday, 16 August 2001 10:25:27 UTC