- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 16 Aug 2001 23:09:16 -0400
- To: w3c-dist-auth@w3c.org
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