Issue #44: REPORT_OTHER_RESOURCE_LOCKED

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 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.044_REPORT_OTHER_RESOURCE_LOCKED>).

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 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.C.6>).

Feedback appreciated,

Julian

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