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

From: Werner Donné <[email-masked]>
Date: Fri, 09 Nov 2007 10:41:30 +0100

Hi,

In the bindings draft the status code 506 is introduced as a
possible response for the PROPFIND method. Is it allowed to
use the status code for other methods as well?

The use-case is a server which doesn't allow the creation of
loops. When an operation would create a loop the status code
could be used to report it. When a server supports bindings
a sequence of MOVE methods could create a loop for example.

Regards,

Werner.
-- 
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803	e-mail: [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Nov 2007 11:37:38 +0100

> use the status code for other methods as well?

I'd say yes, as long as the error is the one defined for 506 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#status.506.loop.detected>):

"The 506 (Loop Detected) status code indicates that the server 
terminated an operation because it encountered an infinite loop while 
processing a request with "Depth: infinity". This status indicates that 
the entire operation failed."

> a sequence of MOVE methods could create a loop for example.

I think it would be better to return a 409 with 
DAV:error/DAV:cycle-allowed here.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Nov 2007 14:29:10 +0100

Julian Reschke wrote:
> ...
> ...

...that being said, I wouldn't be opposed to adding an appendix that 
both illustrates how MOVE requests can theoretically generate a bind 
cycle, and how to handle that case.

BR, Julian

---

From: Werner Donné <[email-masked]>
Date: Sat, 10 Nov 2007 09:12:06 +0100

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.

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.

Regards,

Werner.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 10 Nov 2007 12:26:03 +0100

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

> 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