W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 23] lock discovery vs shared locks

From: Jim Luther <luther.j@apple.com>
Date: Fri, 18 Nov 2005 10:24:16 -0800
Message-Id: <A41993B7-C55C-4F7C-893B-295BEAF65BB6@apple.com>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, Julian Reschke <julian.reschke@gmx.de>
To: webdav <w3c-dist-auth@w3.org>

Our existing code only uses LOCK to (1) get a new exclusive lock and  
(2) to refresh the exclusive locks we own. We parse the lockdiscovery  
response for a lock-token in both cases. I looked through the various  
versions of our code and I *think* that it wouldn't matter if the  
lockdiscovery response were not returned in the LOCK refresh  
response, but without a server to test against, I cannot be sure.

So I agree with Geoff, but would add the requirement of returning the  
lockdiscovery response for a LOCK refresh because it would be useful  
for the same reasons you'd want the lockdiscovery response when a  
lock is created (to get the locktoken, timeout value, etc). This  
should not be a lock privacy problem because the client has proved it  
knows about the lock via the If header in the request.

- Jim

On Nov 18, 2005, at 9:31 AM, Geoffrey M Clemm wrote:

> From a lock privacy perspective, putting all information about the
> newly created lock in the lockdiscovery response to a LOCK
> request is (of course) no problem, so requiring that is fine with me.
> Perhaps the new text could require that full information about a LOCK
> be returned in the lockdiscovery response to a LOCK, while information
> about other locks is optional in the lockdiscovery response to a LOCK.
> Cheers,
> Geoff
> Julian wrote on 11/18/2005 12:06:21 PM:
> >
> > Geoff, any input about how a server concerned with the privacy of  
> lock
> > information would return the actual timeout value (as compared to  
> the
> > one sent by the client)?
Received on Friday, 18 November 2005 18:24:33 UTC

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