Re: Locks and loopback bindings

Julian wrote on 12/03/2004 03:44:41 PM:
 
> Jim Whitehead wrote:
> 
> > Lock really should
> > ignore any loopback binding. While loopback bindings could 
theoretically
> > have existed in the 2518 world, it really is only the introduction of 
the
> > BIND specification that starts raising these issues with any urgency.
> 
> Well, there are good reasons not to implement bind loops at all (this is 

> why the spec explicitly allows servers to reject requests creating them, 

> see DAV:cycle-allowed precondition for BIND). The presence of bind loops 

> creates all kinds of issues, including those what to do with 
> PROPFIND/depth:infinity and code that walks hierarchies and gets into 
> infinite loops. I'm not surprised that Depth:infinity locks in bind 
> loops are hard to handle, but IMHO that only means that one should avoid 

> bind loops :-)

Bind loops are fine.  Depth:infinity applied to bind loops is what
causes the problem.  As Julian indicates, how a particular server decides
to handle Depth:infinity locks in the presence of bind loops (for those
very rare servers, if any, that actually support this) will be very
idiosyncratic to that particular server.  It may decide to fail 
a Depth:infinity lock applied to a loop, or it may decide to lock all
the resources included in the loop.  Or it may decide to do something
totally bizarre(:-) such as Jim's suggestion, that it lock only resources
that aren't parents of the resource being locked.  We need to maintain
a discrete silence here, since we really can't predict what a server
will need to do, or be able to do, in a case like this.  But this is
a very unlikely edge case, and therefore I believe doesn't merit any
spec space devoted to it.

> I remember that Geoff was actually defending the ability to have bind 
> loops, so maybe he can offer some opinion about how locks should behave. 


We will not be supporting depth locks in our loop-supporting repostories.

> Personally, I'd say: "the way they are defined by RFC2518, and if this 
> hurts, don't do it".

I agree, where by "don't do it", I assume you mean "fail an attempt to 
create the lock", and it's got a well-defined error code (506) it it
decides to do so.

Cheers,
Geoff