Re: Locks and loopback bindings

Julian wrote on 12/03/2004 05:26:56 PM:

> Jim Whitehead wrote:
> 
> > The reason I think this is an issue is that I can't envision a 
scenario
> > where you would ever want the lock to follow a loopback binding. That 
is,
> > the reason it is a problem is the locks-follow-the-loopback-binding
> > semantics are never what a client would want.
> 
> I'll not argue with that. But to me this means that if you don't want 
> that, don't do it. The fact that depth:infinity locks have interestings 
> results for bind loops doesn't necessarily mean that the base semantics 
> need to be changed; not doing it if you don't want to certainly is an 
> option as well (and a much simpler one spec-wise).

I completely agree.  Throw a 506 if you don't want to follow the base
semantics.

> > You can make consistent semantics here, by saying that locks always
> > propagate down a hierarchy, but never up. Yes, this is changing the 
base
> > lock semantics somewhat, but in my opinion it doesn't violate the 
intent of
> > 2518. This is essentially adapting the COPY depth infinity semantics 
for
> > locks.
> 
> Sounds interesting; but as I'd like to hear feedback from those who 
> actually see bind loops being used in practice. Geoff??

I don't believe any server would actually maintain a depth:Infinity 
lock only on the "non-ancestor" members, since it would have to perform
expensive recomputations on all involved locks every time a binding
was changed.  It will either do the base semantics (and bind everything)
or fail the depth:lock or the attempt to loop-back under a depth-lock
(with a 506).  We just won't support depth locks on our loop-backing
repositories.

> >>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 :-)
> > 
> > Saying "tut-tut" doesn't make the problems of the interactions of 
loopback
> > bindings and depth locks go away.

Pragmatically, a server will do some combination of:
- support the base semantics,
- fail attempts to create loops,
- fail attempts to do depth locks,
- fail attempts to create a loop under a depth lock, or
- fail attempts to depth lock over a loop

None of these require additional statements in the specification,
and we really cannot (and should not) try to dictate which of these
it does.  And we certainly should dictate it do something computationally
infeasible instead (:-).

> >>Personally, I'd say: "the way they are defined by RFC2518, 
> >>and if this hurts, don't do it".
> > 
> > We can be more nuanced than this.
> 
> We *could*. The question is: do we want to complicate the spec for 
> something that seems to be an edge case? As far as I am concerned, bind 
> loops are something that most implementers won't implement anyway. Let's 

> hear from those who actually want bind loops about what they think about 

> how they should behave with locking.

I agree we should not try to be more nuanced.
The current definitions give the servers all the alternatives they are 
likely
to pick.

Cheers,
Geoff