Re: [Bug 23] lock discovery vs shared locks

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

Cheers,
Geoff

Geoff wrote on 10/29/2005 04:43:39 AM:
> 
> Geoffrey M Clemm wrote:
> > 
> > The last sentence is incorrect.  A lock token appears in a PROPFIND
> > lockdiscovery only if the server wishes to expose it.  I have argued
> > in the past that a sensible server should never expose a lock token in 
a
> > PROPFIND lockdiscovery, since it just allows a client of a user
> > to incorrectly re-use a lock token still in use by another client
> > of that user.  So if we say anything, it should "A server SHOULD NOT
> > include a lock token in a PROPFIND lockdiscovery, since it introduces
> > the possibility of two clients of a given user overwriting each others
> > changes".
> 
> Here I'll disagree with Geoff :-)
> 
> "lock stealing" is further controlled (or can be controlled) by checking 

> the principal as well.
> 
> I *do* agree that it makes sense to have one coherent section that gives 

> advice on how not to reveal lock tokens. For instance, servers are 
> allowed to report the locks, but not to disclose the lock tokens (see 
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.12.1>).
> 
> Best regards, Julian
>