[Zope-dev] WebDAV locks disappearing...

[Jeffrey P Shell]

A WebDAV client may request a timeout length for a lock, but it's basically
just a suggestion.  You say you investigated again "some time later".
Zope's default timeout is thirty minutes.  Clients can ask for longer ones
and Zope will obey, but the 30 minutes is granted for 'infinite' timeout
requests (the spec says that the server may decide the timeout time
independent of the clients request).  The timeout should get refreshed with
every HTTP request made by you (the lock owner).  But the timeout also
exists so that the problem of "Person X locks a document for editing, and
then leaves in a hurry (forgetting to release his lock).  Person Y really
needs to edit the document, but it's held hostage by X's lock".

Cadaver may be caching the locks.  Since HTTP/WebDAV are stateless, you have
to refresh your listing in order to see if locks are still there.  Most GUI
based WebDAV clients have a "refresh listing" option, which is the only way
they can know of new members in a collection and new lock states.

On 3/7/02 11:38 AM, "Jerome Alet" <alet@unice.fr> wrote:

> Hi,
> 
> I've just tested webDAV access for the very first time using cadaver,
> so maybe this is a known problem.
> 
> I've locked some objects using cadaver's lock command, and then opened
> a browser keeping cadaver's connection opened.
> 
> then I've searched for this locks using the ZMI and also a method of
> my own.
> 
> All worked fine, the locks were found.
> 
> Then some time later I've retried to find the locks, and both the
> ZMI and my method returned no lock. However in cadaver the locks
> still seemed to be there...
> 
> Then I've unlocked the objects and relocked them in cadaver and
> retried, this time the locks were found again...
> 
> I hadn't the time to do some more testing but I find this
> surprising.
> 
> Does anyone have seen the same problem ?
> 
> FYI Zope 2.5.0 + Python 2.1.2 both up-to-date Debian Woody
> packages.

-- 
Jeffrey P Shell 
www.cuemedia.com