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

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

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.

Received on Thursday, 16 August 2001 18:14:42 UTC