W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

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

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 30 Jun 2004 10:23:40 -0700
Message-Id: <3A8A5A6B-CABA-11D8-93E4-000A95B2BB72@osafoundation.org>
To: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT