Re: Locks and loopback bindings

Jim Whitehead wrote:

> Ah! Thanks for figuring this out. So, REBIND really moves the head of the
> binding from one place to another. I was assuming it moved the tail from one
> place to another.
> 
> I'll have to rethink the desired example.

Great....

>>The other obviously open question was whether bind loops need 
>>special treatment regarding depth:infinity locks. I wasn't 
>>under the impression they do. Is there a specific problem 
>>that needs to be solved?
> 
> 
> Well, there are two issues. One is the handling of If headers for loopback
> bindings. The other is the semantics of the lock operation in the presence
> of loopback bindings. I think the handling of If headers is relatively
> straightforward. The semantics of locking are not.
> 
> Consider the following collection hierarchy:
> 
> +------------------+
> | Root Collection  |
> |  bindings:       |<---------------------+
> |  CollW           |                      |
> +------------------+                      |
>      |                                    |
>      |                                    |
>      |                                    |
> +-------------------------------+         |
> | Collection C1                 |         |
> | bindings:                     |         |
> | CollX               CollY     |         |
> +-------------------------------+         |
>      |                  |                 |
>      |                  |  (creates loop) |
>      |                  |                 |
> +-----------------+  +------------------+ |
> | Collection C2   |  | Collection C3    | |
> | bindings:       |  | bindings:        | |
> |  {none}         |  | y.gif     CollZ  | |
> +-----------------+  +------------------+ |
>                        |            |     |
>                        |            +-----+
>                        |
>                    +---------------------------+
>                    | Resource R2               |
>                    +---------------------------+
> 
> What is the outcome of an exclusive LOCK, depth infinity, submitted to
> /CollW/CollY/ ?
>
> Seems to me, the desired outcome is that only C3 and R2 are locked. 

Well, I would expect the lock to behave as defined by RFC2518, 
effectively locking the whole namespace.

> However, if you read 2518, section 8.10.4 (Depth and Locking), it says:
> 
> "If the Depth header is set to infinity then the resoruce specified in the
> Request-URI along with all its internal members, all the way down the
> hierarchy, are to be locked." 

Why is that a problem? A bind loop that includes the namespace root 
seems like an edge case to me that doesn't require changing the base 
semantics. If it hurts to have a bind loop including the namespace root, 
don't do it.

> In the binding specification, we define an Internal Member URI as 
> 
> "The URI that identifies an internal member of a collection, and that
> consists of the URI for the collection, followed by a slash character ('/'),
> followed by the path segment of the binding for that internal member." 
> 
> So, following these two definitions, one would interpret CollZ as an
> internal member URI, and then have the lock request apply to it, in this
> case locking the root collection, and all of its internal members, etc. What
> happens next is unclear. Either the lock fails (because /CollW/CollY/ is
> already locked), or the entire URL hierarchy on the server is added to the
> lock. 
> 
> 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 :-)

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. 
Personally, I'd say: "the way they are defined by RFC2518, and if this 
hurts, don't do it".

Best regards, Julian



-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 3 December 2004 20:45:18 UTC