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

Re: [Bug 23] lock discovery vs shared locks

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 29 Oct 2005 15:12:06 +0200
Message-ID: <43637526.1010406@gmx.de>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
CC: webdav <w3c-dist-auth@w3.org>

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
Received on Saturday, 29 October 2005 13:12:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT