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

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