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

(sort-of) new LOCK refresh/depth issue

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 17 Jul 2004 11:31:04 +0200
Message-ID: <40F8F1D8.50003@gmx.de>
To: WebDAV <w3c-dist-auth@w3.org>

Hi,

Lisa reminded me of a question asked by Stanley half a year ago:

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0300.html>

"Under the topic of "Refreshing Locks", it hints that Client may include 
a Timeout header. But, Depth header has not being mentioned.

Under the topic of "Depth and Locking", it discussed what will happen if 
"Depth" header is specified for creating a new lock.  But, nothing was 
mentioned on what's its implication on a lock refreshing command."

First of all, I've added this to my issues list as 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.5.2.1-depth_header_vs_lock_refresh> 
(will show up next week).

When discussing the question we listed the options below:

1) server MUST respect Depth header, possibly changing the lock scope
2) server MAY respect Depth header, possibly changing the lock scope
3) server SHOULD ignore Depth header
4) server MUST ignore Depth header

plus (by Lisa D.)

5) Another option is to reject the request if the Depth header is 
present and has the wrong value.

Technically, 5) makes sense; but it would break clients that take out 
Depth: 0 locks on resources but then don't specify Depth: 0 on a lock 
refresh (the Depth: header defaults to 'infinity' for the LOCK method).

In the meantime I have tested at least Office2003, which indeed 
specifies the Depth: 0 header upon LOCK refresh; thus would continue to 
work. I'm unsure about other clients (older Office versions, Xythos, 
MacOSX), so I'd still prefer option 4 (and this is what I'll put in into 
my locking document, as it seems the clarification with the lowest risk 
of breaking anything).

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 17 July 2004 05:31:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT