- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 10 Aug 2001 17:24:31 -0400
- To: w3c-dist-auth@w3c.org
I agree with Jim. Timeouts should only be reset by an explicit request to do so, not as a side-effect of a request that uses the lock token. Cheers, Geoff -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, August 10, 2001 3:25 PM To: w3c-dist-auth@w3c.org Subject: Re: rfc2518 issue: LOCK_REFRESH_BY_METHODS And there's the issue associated with lock owner (not the owner element of the lock discovery which is a lock owner display name). Should the locked resource be accessed by any principal who has the lock token, or only the principal that issued the LOCK method to create the lock token. If any user can issue a PROPFIND to get the DAV:lockdiscovery and therefore the lock token, and then use that lock token to do anything to the locked resource, the usefulness of WebDAV locking would be limited. On the notion of refreshing locks, users create, refresh, and release locks. The less the server does on their behalf the better. Having timeouts on locks is fine, but let's keep it simple. A user locks a resource with a timeout that generally represents how long they expect to keep the lock and therefore limit access to the resource by others. To have this timeout reset on every successful method invocation would make lock timeouts very non-deterministic and much more difficult for users to predict what will happen when. I think locks timeouts should only be refreshed when the user says to refresh them. Jason Crawford To: w3c-dist-auth@w3.org 08/10/2001 cc: jamsden@us.ibm.com 02:41 PM From: Jason Crawford/Watson/IBM@IBMUS Subject: rfc2518 issue: LOCK_REFRESH_BY_METHODS(Document link: Jim Amsden) It sounds like we're winding down on the locknull discussions, so here's the next issue.... Jim Amsden brought up the following issue. I don't have a record of us resolving it, so let's do that. The specification requires a lock to be refreshed if any method is executed, by anybody, on a locked resource. This can cause some performance problems. More importantly, the semantics of this refresh do not seem to be right -- why should a random GET by a third party cause all locks to be refreshed? The text in question seems to be: The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. In section 9.8 of RFC2518. Also... contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). in section 8.10.8 seems to be alluding to the same behavior. Do we want to change 2518? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com
Received on Friday, 10 August 2001 17:15:26 UTC