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

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 15 Aug 2001 17:51:33 -0400

From: Jason Crawford [mailto:[email-masked]]

   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.

Cheers,
Geoff

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 16 Aug 2001 01:45:15 -0400

<<

   My opinion is that...

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.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 16 Aug 2001 12:24:13 -0400

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

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 16 Aug 2001 18:13:03 -0400

<<
And I might find that acceptable, but I'd think the long term view is that
we keep it seperate and orthogonal, so I'm going to continue to advocate a
seperate header.

First a question though: I did a quick read of the spec last night.   Can
there be more than one IF: header for a given request?

Proposal:  Let's propose a new header (for clarity of this note, let's call
it "submitted-ltokens:").   We can work out what the syntax is for that
after some discussion, but we could start with something similar to what
Geoff proposed in his last note.  This should provide a very clean spec,
but we could optionally add some text to bring attention to the fact that
token presentation has changed.

With that spec in place, the implementations would want to implement a
transition strategy.  For servers, if the submitted-ltokens header is
included, the prudent servers would only check that header for the purpose
of token submission purposes.  If the new header is not included in the
request, the prudent server would check the IF header for token submission
along the vaguely specified (aka unspecified) lines of 2518.  In both
cases, the IF header would be checked as documented by 2518 section 9.4.

For prudent clients the transition strategy would be to simply submit both
the new header and the if header.  This would insure that they could work
with old servers and new servers.

Is this reasonable?

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 17 Aug 2001 09:21:44 -0400

From: Rashmi Singh [mailto:[email-masked]]

   Do we agree on
   rejecting the PUT submitted with invalid lock token on an unlocked
   resource.  Just to make things explicit, the same applies to COPY and
   MOVE also.

Assuming it is sumitted in a non-negated no-tagged list,
or in a non-negated tagged list that specifies the unlocked
resource, then yes (by the definition of the If header, not
by any special locking semantics).

   i) COPY - What if COPY is submitted with an invalid locktoken for
   unlocked destination?

Invalid, for same reason as above.

   ii) MOVE - What if MOVE is submitted with an invalid locktoken for
   either an unlocked source or an unlocked destination?

You have to be specific about what you mean by "submitted", i.e.
what exactly are you planning on sending in the If header?
Assuming you meant the simplest thing, i.e. a non-negated no-tagged
list, then yes, the locktoken must match both the source and
the destination of the MOVE.  What 2518 leaves open and ambiguous
is whether it must also match both the source collection and
the destination collection.  I would argue, yes, because both
of those collections are being modified by the MOVE.

   Should we return 412 (Precondition failed) in the above case?

Yes.

Cheers,
Geoff

---

From: "Jason Crawford" <[email-masked]>
Date: Fri, 17 Aug 2001 20:58:35 -0400

I'm pretty neutral on this, so I'll go along with whatever
  is the consensus (assuming that there is one :-).

  OK, on those grounds, I'll switch my vote to a new header, which
  takes a comma separated list as its argument!

  I pretty much abhor all abreviations, so I'd prefer something like
  "Lock-Token-Set".

If more one person pipes up in favor of spec'ing a new header for lock
token presentation in principle, I'll write up a proposal.....

Is anyone else supportive of this?

J.