Subject: Issue #44: REPORT_OTHER_RESOURCE_LOCKED

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Jun 2004 21:43:52 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 19 Jun 2004 15:38:53 +0200

Full text:

7.2.2  DAV:need-lock-token precondition

    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.  [[anchor28: Copied from GULP.  --reschke]]

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

    Servers SHOULD insert DAV:href elements for the URLs of each root of
    a lock for which a lock token was needed, unless that URL identies
    the same resource to that the request was sent.

7.2.2.1  Example

    In the example below, a client unaware of a "Depth: infinity" lock on
    the parent collection "/workspace/webdav/" attempts to modify the
    collection member "/workspace/webdav/proposal.doc".

    >>Request

       PUT /workspace/webdav/proposal.doc HTTP/1.1
       Host: example.com

    >>Response

       HTTP/1.1 423 Locked
       Content-Type: text/xml; charset="utf-8"
       Content-Length: xxxx

       <?xml version="1.0" encoding="utf-8" ?>
       <D:error xmlns:D="DAV:">
         <D:need-lock-token>
           <D:href>/workspace/webdav/</D:href>
         </D:need-lock-token>
       </D:error>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 23 Jun 2004 22:38:00 -0400

This precondition sounds fine to me.

I wouldn't say it applies to all methods though; only methods that
modify state on the server (e.g., not PROPFIND or the various
REPORT's).

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jun 2004 08:57:57 +0200

> modify state on the server (e.g., not PROPFIND or the various

Right now it starts saying... "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,", thus it *does* apply to 
all methods.

An alternative would be to re-group the conditions; but that would only 
make case if we find more that fall into the same category...

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 24 Jun 2004 08:26:29 -0400

Good point ... it is probably simplest to leave it the way you
currently define it.

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 30 Jun 2004 10:46:09 -0700

I'm mostly happy with this, although as with much of the specs where 
preconditions are defined, it doesn't say in which cases the server 
MUST (or SHOULD or MAY) return this precondition.  For backward 
compatibility, I suggest that servers SHOULD or MAY return this 
precondition in the body of a 423 Locked response.  Other commenters?  
Will servers actually implement this?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2004 20:11:09 +0200

Lisa Dusseault wrote:

> preconditions are defined, it doesn't say in which cases the server MUST 
> (or SHOULD or MAY) return this precondition.  For backward 

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#method.preconditions.and.postconditions> 
makes this a "MUST" level requirement. Realistically, we may want to 
make that a SHOULD, because it may be hard for some servers to implement 
that (on the other hand we *do* want them to implement the more 
important changes such as DAV:lockroot). And after all, no big harm is 
done when it's not returned.

Feedback appreciated.

Julian