Re: The use of status code 506 (Loop Detected)

Werner Donné wrote:
> Say we have the path /A/B/C/D/ where D/ is in fact a second
> binding to /A/E/F/. If you move /A/B/ to /A/E/F/ you get
> /A/E/F/B/C/D/. Because of the binding this is the same as
> /A/E/F/B/C/F/, which is a loop. Note that we did a move of B/,
> which is not involved in any binding itself.

Yep.

Essentially it can occur anytime a collection is moved below another 
collection a descendant already binds to.

A simpler example would be (set your mail reader to monospaced font...):

We start with the root collection, and just two collections C1 and C2:

                  +------------------+
                  | Root Collection  |
                  |  bindings:       |
                  |  CollX    CollY  |
                  +------------------+
                      |          |
                      |          |
         +------------------+    |
         | Collection C1    |    |
         |  bindings:       |    |
         |           CollZ  |    |
         +------------------+    |
                      |          |
                      |          |
                  +------------------+
                  | Collection C2    |
                  |                  |
                  |                  |
                  +------------------+

So C1 is identified by "/CollX", and C2 is identified by both "/CollY/" 
and "/CollX/CollZ/" (choosing names consistent with other examples from 
the spec).

Issueing a MOVE request:

MOVE /CollX HTTP/1.1
Host: example.com
Destination: /CollY/CollX

will result in:

                  +------------------+
                  | Root Collection  |
                  |  bindings:       |
                  |           CollY  |
                  +------------------+
                                 |
                                 |
         +------------------+    |
         | Collection C1    |    |
  +----> |  bindings:       |    |
  |      |           CollZ  |    |
  |      +------------------+    |
  |                   |          |
  |                   |          |
  |               +------------------+
  |               | Collection C2    |
  |               |  bindings:       |
  |               | CollX            |
  |               +------------------+
  |                   |
  |                   |
  +-------------------+

So this move has created a bind cycle, for instance C2 is now identified 
by "/CollY/", "/CollY/CollX/CollZ/", "/CollY/CollX/CollZ/CollX/CollZ/" 
and so on.

It seems to me it would be good to mention this as an additional example 
below Section 2.5, "MOVE and Bindings".

> It is also possible to introduce a second binding to a resource
> without actually supporting the BIND method. Let's take a versioning
> server, for example, with auto-version set to manual for /A/B/
> and /A/C/. Say we want to move /A/B/D to /A/C/D. We have to
> check out /A/B/ and /A/C/, provided we support versioning of
> collections. After the move we check in /A/C/, but we undo the
> check-out of /A/B/. We are then left with /A/B/D and /A/C/D,
> both referring to the same resource.
> 
> So loops could occur without the binding spec being supported.

That's one way to phrase it.

Another way would be to recognize that parts of RFC3253 have been 
depending on semantics defined in the BIND spec all the time. To 
properly implement these parts of RFC3253, a server may not need the new 
protocol elements defined by BIND, but at has to follow the data model.

I've been arguing this again and again whenever the WG had been delaying 
publication of BIND, but apparently, I wasn't able to convince the 
decision makers.

BR, Julian

Received on Saturday, 10 November 2007 11:26:20 UTC