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: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 30 Jun 2004 20:30:19 +0200
Message-ID: <40E306BB.6080601@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>

Lisa Dusseault wrote:

> 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.

Right now I'm saying:

	 The UNLOCK method removes the lock identified by the lock token in the 
Lock-Token request header from the resource identified by the 
Request-URI, and all other resources included in the lock. Note that the 
UNLOCK request may be submitted to any resource locked by that lock 
(even those that are locked indirectly).

..but I guess this is equivalent.

> 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.

For the case where the lock-token header *is* present I defined:

"5.2.1 DAV:lock-token-matches precondition

The lock identified by the "Lock-Token" request header exists, and the 
resource identified by the Request-URI indeed is directly locked by the 
specified lock."

so you'd get a 403 with DAV:error in this case. The more preconditions 
we precisely identify, the less new clients will have to rely on 
specific 4xx codes...

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 30 June 2004 14:30:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:31 UTC