Issue #66: MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL

Hi all,

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

"Right now the server uses the IF: header to verify that a client knows 
what locks it has that are affected by an operation before it allows the 
operation.  Must the client provide the root URL of a lock, any URL for 
a pertainent loc, or some specific URL  in the IF: header.

Post: 
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0055.html: 
It is felt by the group that it’s important that the client not just own 
and hold the lock token, but that it also know where the lock is rooted 
before it does tasks related to that lock.  This is just a point of 
info.  The issue itself still needs to be brought up and answered.still"

(see also 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL>)

I just did some test with Apache/moddav2, Xythos and SAP Enterprise 
Portal 5 (IIS doesn't support deep locks; test case script attached). It 
seems that none of these servers is indeed enforcing that in tagged if 
lists, the *root* of the URL needs to be submitted. That is, it doesn't 
matter which of the resources locked by a deep lock is listed in the 
tagged-list, as long as it is indeed affected by the lock.

This leaves us with the following options:

1) Just document things as they seem to be implemented (not requiring 
that the client uses the URI of the lock root),

2) Keep our earlier statement -- basically clients MUST submit the lock 
token with the URL of the lock root; and state that otherwise the 
behaviour is server-defined (thus interoperable).

As 2) is what we discussed before, I think I prefer that point of view. 
However, if people think we should explicitly allow 1), I'll happily 
document that as well.

Feedback appreciated,

Julian

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