RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS

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