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

Re: Locks and loopback bindings

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 03 Dec 2004 23:26:56 +0100
Message-ID: <41B0E830.6060804@gmx.de>
To: ejw@cs.ucsc.edu
CC: "'WebDAV (WebDAV WG)'" <w3c-dist-auth@w3.org>

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).

> 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??

>>>In both cases, this seems like undesirable semantics. 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 :-)
> Saying "tut-tut" doesn't make the problems of the interactions of loopback
> bindings and depth locks go away.
>>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.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 3 December 2004 22:27:40 UTC

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