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


From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 18 Jun 2004 21:43:52 +0200
Message-ID: <40D345F8.9050106@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
Hi all,

quoting from <http://www.webdav.org/wg/rfcdev/issues.htm>:

"In some cases, such as when the parent collection of a resource is 
locked, a 423 (Locked) status code is returned even though the resource 
identified by the Request-URI is not locked. This can be confusing, 
since it is not possible for a client to easily discover which resource 
is causing the locked status code to be returned. An improved status 
report would indicate the resource causing the lock message."

(see also 

I just did tests - again - with Apache/moddav2, Xythos and SAP EP5 (test 
case attached), confirming that all of them indeed return 423 Locked.

So I'd recommend that we define a new precondition (applying to *all* 
methods) specifically for use in this case, that also will contain the 
URI of the resource causing the failure inside a <href> element, similar 
to <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1> 
(where the same situation occurs for missing privileges).

For instance:

(DAV:need-submitted-lock-token): If a request would modify the content 
for a locked resource, a dead property of a locked resource, a live 
property that is defined to be lockable for a locked resource, or an 
internal member URI of a locked collection, the request MUST fail unless 
the lock-token for that lock is submitted in the request. An internal 
member URI of a collection is considered to be modified if it is added, 
removed, or identifies a different resource.

<!ELEMENT need-submitted-lock-token (href)* >

(the text is taken from one of the GULP rules, see 

Feedback appreciated,


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 18 June 2004 15:44:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:29 UTC