Re: Call for consensus on UNLOCK Request-URI being lock root

Here's proposed text to use if we end up allowing UNLOCK against any 
resource covered by the lock token, as is currently the case in most 
implementations:

    The UNLOCK method identifies a lock to remove with the lock token in
    the Lock-Token request header.  The Request-URI MUST identify a
    resource within the scope of the lock.

Then later in the error code information for UNLOCK:

    400 (Bad Request) - No lock token was provided, or request was
    made to a Request-URI that was not within the scope of the lock.

Lisa

On Jun 27, 2004, at 1:57 AM, Julian Reschke wrote:

> Jason Crawford wrote:
>> On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault  wrote:
>>  > This would overturn a consensus that had previously been 
>> determined at
>>  > a WG meeting that happened together with an interoperability 
>> meeting,
>>  > and the consensus was not challenged on the mailing list at that 
>> time.
>>  >
>>  > However, given that we have new information -- actual research!
>>  > (thanks) -- it does make sense to reconsider.
>>  >
>>  > WG members please indicate your old, new, and/ or current 
>> preference,
>>  > with reasons if they've not already been stated here:
>>  > 1. Should servers accept an UNLOCK request where the Request-URI 
>> names
>>  > any resource covered by the lock named in the lock token?
>>  > 2. Or, should servers redirect that UNLOCK request to the root of 
>> the
>>  > lock?
>>  > 3. If something else, please explain.
>> No strong preference so just go with what existing servers do.
>
> What do you mean by "redirect"? Please be more specific.
>
> No strong preference either, but some thoughts:
>
> a) Whatever the consensus and the resolution is, it needs to be 
> recorded in the official issues list. Right now it says that any URI 
> of a resource protected by the lock works.
>
> b) I think we *should* be documenting what is implemented, not what we 
> think RFC2518 should have said in the first place. The servers I 
> tested do implement behaviour 1).
>
> c) If we only allow UNLOCK on the lock root, we still still need to be 
> clear about what the result of other UNLOCK requests are? Undefined? 
> 4xx status? In the latter case, all the servers I tested need to be 
> updated, and we *may* be breaking existing clients.
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 30 June 2004 13:23:55 UTC