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


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
Message-ID: <OF6E4F3F4B.2D6FDFFB-ON85256AA4.00652044@pok.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.


   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?


Phone: 914-784-7569,   ccjason@us.ibm.com
Received on Friday, 10 August 2001 14:58:30 UTC

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