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

RE: Locks and loopback bindings

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 7 Dec 2004 21:57:24 -0500
To: "'WebDAV \(WebDAV WG\)'" <w3c-dist-auth@w3.org>
Message-ID: <OF5FA1FA66.65F08A03-ON85256F64.000EBCD0-85256F64.00103EF6@us.ibm.com>
The major reason to not change standard behavior in the way Jim suggests
is that this will break existing clients.  In particular, if a user depth
locks a collection, a standard depth locking client will assume that the
lock token will apply to all the members of that collection, and will pass
that lock token in any edit request the user makes to a member of that

But with the semantics that Jim suggests, some of those members will 
mysteriously unlocked, and the editor just fails with "unexpectedly 
lock" when the user attempts to edit (or even worse, allows the user to 
an unlocked resource, without overwrite protection). 

Now let's contrast this with the scenario Jim describes.  Surely any 
that is bold enough to support both binding loops and depth locking would
support the DAV:lockroot property introduced a while ago to solve exactly
this problem of not knowing where a lock comes from.  This means that
neither Bob nor Alice is ever surprised or mystified about an "unexpected
lock", because the DAV:lockroot says exactly where it came from.  And if
they want to discover the path back to the lock root, they just use the 
parent-bindings property to walk back through the locked parents until 
find the root (or if they have a civilized client, their client will do 
walk for them, and report the path from the lock root to the locked 

So "overlocking" is always easily explained, and is the expected behavior 
for existing clients, while "underlocking" is both mysterious (how does a
user use a standard client to discover why the member isn't locked?) and 
significantly, will break existing clients that expect the standard depth
locking behavior.


Jim wrote on 12/07/2004 07:32:47 PM:

> > I'm still not sure why you call that a "problem". As far as I 
> > can tell, it works exactly as designed.
> Here is a plausible scenario that outlines why I think this is a 
> Assume there is a collection hierarchy rooted at a collection with
> non-unique pathname /collA/collB/collC/collD. Within this hierarchy 
there is
> one loopback binding to /collB/, one of approximately 500 bindings 
> the collD hierarchy. There is only the one loopback binding in the 
> collD hierarchy.
> Alice wants to work on the /collA/collB/collC/collD hierarchy, and wants 
> ensure she can make changes to multiple documents to ensure their 
> are consistent with one another. (Alice should probably be using DeltaV
> workspaces for this, but that's another matter). So, Alice depth locks 
> entire hierarchy, by submitting her lock request to
> /collA/collB/collC/collD.
> Bob knows that Alice is working on /collA/collB/collC/collD because they
> talked about her doing so at their staff meeting in the morning. So, he 
> surprised to discover that the area where he was supposed to work,
> /collA/collB/collE/collF, is locked by Alice. Bob phoned Alice and asked 
> why she had locked his work area, and Alice replied that she hadn't, and 
> confused as to why Bob thought this. Bob replied that his authoring tool
> reported her as owning the locks on those resources, and that she had 
> his entire resource space.
> Alice uses WebDAV Explorer to unlock /collA/collB/collE/collF (good 
> DAV Explorer automatically retrieves and applies the lock token it finds 
> the lockdiscovery header, otherwise Bob and Alice would really have a 
> time :-) However, she's then confused as to why the locks on her 
> space have disappeared. So she locks /collA/collB/collC/collD, only to 
> out that she can't take out the lock anymore. Frustrating. She asks Bob 
> he was able to take out a lock. Yes, he says, now I'm able to take out 
> lock and work.
> Strange, thinks Alice, it's as if the system only allows one of us to 
> at a time. Not understanding what is going on, and have received no 
> messages from her software that would lead her to think that a loopback
> binding is causing the problem, she calls her firm's technical support.
> Since most existing hierarchy browsers for WebDAV do not give any 
> into loopback bindings, it's anyone's guess as to how long it will take
> technical support to determine the root cause of the problem.
> - Jim
Received on Wednesday, 8 December 2004 02:57:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC