Re: [Bug 23] lock discovery vs shared locks

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
>  >