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

Re: (sort-of) new LOCK refresh/depth issue

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sat, 17 Jul 2004 07:56:17 -0400
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OFD4EC9880.E11B1E19-ON85256ED4.0041664D-85256ED4.00419462@us.ibm.com>
I agree that (4) is the best approach.


Julian wrote on 07/17/2004 05:31:04 AM:
> 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).
Received on Saturday, 17 July 2004 07:56:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:30 UTC