Issue #56: DEPTH_LOCK_AND_IF

Hi,

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

"The specification is currently silent on how to use the If header for 
submitting a locktoken when performing a DELETE in a Depth infinity 
locked collection.  Should the If header have both the collection URL 
and the Request-URI, or just the Request-URI? An example of this is needed."

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

I just did tests - again - with Apache/moddav2, Xythos and SAP EP5 (test 
case attached), confirming that all accept the DELETE request no matter 
for which URI the lock token is submitted.

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html> 
currently defines:

"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."

and GULP (still to be integrated says) goes on saying:

"A lock token is "submitted" in a request when it appears in an "If" 
request header." 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#semantics.5>)

Summary: the server behaviour we see is consistent with GULP (you need 
to submit the lock token, and it counts as submitted if it appears 
anywhere in the "If" header).

The locking spec *still* needs to define the specifics of lock token 
evaluation in the "If" header, though (so I'll add the comments above to 
the issue and move it down to the "If header considerations" section).


Julian


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