W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

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

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 16 Aug 2001 12:24:13 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AB52@SUS-MA1IT01>
To: w3c-dist-auth@w3c.org
   From: Jason Crawford [mailto:ccjason@us.ibm.com]

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

I agree that this is not made clear, and should be.  Let's try:

 "Submitted" means "appears in an operator-free If header list
 (e.g. no "not" operator in the list) that either is a tagged list
 with a URI that identifies the locked resource, or is a no-tagged
 list.

   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?

By the above definition, this would not succeed.

   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.

Not by the above definition.

   If you use a 'not' construct, can it be
   considered to be submitted?

Not by the above definition.

   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?

The "no operator in list" wording was to eliminate this concern.

   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.

I agree with your point about the If header being excessively
overloaded, but for compatibility with existing implementations, I'd
try to fix the problem by clarifying how lock tokens should appear in
If headers, rather than defining a new header.

Cheers,
Geoff
Received on Thursday, 16 August 2001 12:15:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT