Re: [Bug 23] lock discovery vs shared locks

I agree that one needs to deal with the problem of failed clients,
but the correct way for the client to do so is with an
UNLOCK/LOCK sequence, and not by using a lock token that it obtains
from a PROPFIND.  This handles the case where it turns out that the
original client hadn't failed, but was just suspended.  With an 
UNLOCK/LOCK
sequence, the original client will get a failure on PUT because
its lock token is no longer valid.  With a re-use of the lock token
obtained with a PROPFIND, the original client's PUT will succeed
and overwrite changes made by the client that stole the lock token.

Cheers,
Geoff

Lisa Dusseault <lisa@osafoundation.org> wrote on 10/30/2005 10:51:58 AM:

> I mostly agree with this, except with the problem of failed clients. 
> If I use a WebDAV client that crashes and loses its locks, or has a bug 
> and fails to unlock -- or if I'm testing client or server software -- I 
> need a way to get the lock token to remove it as a last resort.
> 
> So yes, while clients SHOULD get the lock token on LOCK response and 
> remember it, there needs to be a way to recover without administrator 
> intervention.
> 
> Lisa
> 
> On Oct 29, 2005, at 8:55 PM, Geoffrey M Clemm wrote:
> 
> >
> > To be clear, I am completely in favor of a server exposing all of
> > the locks on a resource to an authorized user ... I am only against
> > revealing the lock-token in the information on the lock.
> >
> > As for clients that use lock-discovery instead of keeping track of
> > lock tokens, their implementor clearly didn't understand the purpose
> > of a lock token (preventing a user from overwriting his own changes 
> > from
> > another of his clients), and the specification should make this 
mistake
> > clear, and not encourage it.
> >
> > So I agree with Julian's final suggestion that this issue merits a
> > paragraph guiding clients on how to use lock tokens properly, and
> > guiding servers on how to deal with poorly implemented clients.
> >
> > Cheers,
> > Geoff
> >
> >
> > Julian wrote on 10/29/2005 09:12:06 AM:
> >
> >  >
> >  > Geoffrey M Clemm wrote:
> >  > >
> >  > > The likelihood of damage from lock stealing can be decreased by
> >  > > only allowing a given user/principal to steal his own locks, but
> >  > > (as indicated in my original message below :-) it does not 
prevent
> >  > > two clients of a given user/principal from overwriting each 
others
> >  > > changes.  Since there is a completely safe way of handling this
> >  >
> >  > Partly correct. Some clients put stuff into DAV:owner in order to 
> > ensure
> >  > that they can recognize the locks they created, but of course 
that's
> >  > lame compared to just remembering which locks one created in the 
> > first
> >  > place.
> >  >
> >  > > scenario (i.e., streaming an UNLOCK/LOCK sequence to the server),
> >  > > I maintain my position that a client should never "steal"
> >  > > a lock by discovering the lock-token via PROPFIND, even if that
> >  > > lock was held by another client of that same user, and therefore
> >  > > lock tokens should never be exposed in a PROPFIND.
> >  >
> >  > Well, from a purely theoretical point of view, I agree. In 
practice,
> >  > clients do lock discovery instead of keeping track of their locks 
on
> >  > their own, so these clients wouldn't work in this case.
> >  >
> >  > BTW: if a server does not want to expose lock tokens, it can also 
> > show
> >  > the locks, but leave out the DAV:locktoken child element. Anyway, 
> > this
> >  > is certainly a topic where on coherent paragraph would make a lot 
> > of sense.
> >  >
> >  > Best regards, Julian
> >  >