- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 30 Jun 2004 20:30:19 +0200
- 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