Re: [Bug 23] lock discovery vs shared locks

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
>