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

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

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Sat, 17 Jul 2004 09:33:38 -0700
Message-Id: <0E7784BE-D80F-11D8-AE07-000A95B2BB72@osafoundation.org>
Cc: " webdav" <w3c-dist-auth@w3.org>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>

I can agree with (4) too.

My intent with (5) was that only if the client actually *sent* the  
header (not if it was inferred or defaulted to 'infinity') would the  
server look at it and compare the value.  So it wouldn't break any  
clients unless they were doing something seriously confusing.  But that  
seems like pointless extra work for the server.


On Jul 17, 2004, at 4:56 AM, Geoffrey M Clemm wrote:

> I agree that (4) is the best approach.
> Cheers,
> Geoff
> 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 12:33:58 UTC

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