W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 23] lock discovery vs shared locks

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sat, 29 Oct 2005 23:55:52 -0400
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF990A97FC.6ECACC2F-ON852570A9.005343DC-852570AA.00159A85@us.ibm.com>
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.


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 
> Best regards, Julian
Received on Sunday, 30 October 2005 03:55:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC