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

The original question still remains unanswered.  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.

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

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

Rashmi.

"Clemm, Geoff" wrote:
> 
>    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 Friday, 17 August 2001 07:57:49 UTC