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

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

   [geoff] 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.

   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.

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

   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?

Interesting question.  RFC 2616 only allows multiple headers with
the same value if the arguments of that header are defined to be
a comma separated list.  For some reason known only to the authors
of 2518, the arguments to the If header are defined to be a *space*
separated list, so no, there cannot be more than one If header.
(Note that the DAV and the Timeout headers are defined sensibly
to be a comma separated list, so you can have multiple DAV and Timeout
headers).

JimW et. al.  What *were* you thinking?!?  (:-)

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

   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.

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

   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?

OK by me.  I'm still shaking my head over the choice of a space separated
list for the If header (:-).

Cheers,
Geoff

Received on Thursday, 16 August 2001 23:09:52 UTC