- From: Jim Amsden <jamsden@us.ibm.com>
- Date: Fri, 10 Aug 2001 15:24:46 -0400
- To: w3c-dist-auth@w3c.org
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 15:32:10 UTC