- From: Jason Crawford <ccjason@us.ibm.com>
- Date: Fri, 10 Aug 2001 14:41:13 -0400
- To: w3c-dist-auth@w3.org
- Cc: jamsden@us.ibm.com
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 14:58:30 UTC