Re: Bindings and GULP again

I can live with that, however the cases where a "wrong" URL makes a
difference are rare. Given the history of lock difficulties, I favor the
simplistic approach to regard every lock token in a if header as 
submitted.

As you said, the "right" URL only counts in tagged production and a
server should reagard any lock token in an untagged production as
submitted anyway.

That leaves tagged productions with "wrong" URLs as making
the difference in the two proposals. However a wrong URL in
IF headers will only survive (e.g. not throw 412 responses) when
the lock is either negated or part of an "or" list which has one valid
entry.

So, I'd go for the simpler approach which is also easier to define
(so, likely easier to implement correctly).

//Stefan

Am 01.01.2004 um 16:01 schrieb Geoffrey M Clemm:

>
> I assume that this is just a statement about current client behavior.
>
> I would prefer to state that the token must appear with the right
> URL (when in a tagged list), and then in an "interop" section state
> that a server may consider the token to be submitted even if it appears
> with the wrong URL, to handle older clients.
>
> But if other folks prefer just the "anywhere in the If header,
> even with the wrong URL" semantics, I won't object.
>
> Cheers,
> Geoff
>
> Julian Reschke <julian.reschke@gmx.de> wrote on 12/30/2003 05:43:01 AM:
>
>> Quoting section 7.6:
>>
>>     In order to prevent these collisions a lock token MUST be 
>> submitted
>>     by an authorized principal for all locked resources that a method
>>     may change or the method MUST fail.  A lock token is submitted 
>> when
>>     it appears in an If header.  For example, if a resource is to be
>>     moved and both the source and destination are locked then two lock
>>     tokens must be submitted in the if header, one for the source and
>>     the other for the destination.
>>
>> I can live with that, but I'm not sure why this is better than 
>> requiring
>
>> the token to appear with the right URL (when in a tagged list). Is 
>> this
>> just a statement about current client behaviour, or a change compared 
>> to
>
>> RFC2518?

Received on Sunday, 4 January 2004 05:33:03 UTC