W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings)

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sun, 3 Aug 2003 09:17:49 -0400
To: w3c-dist-auth@w3.org
Message-ID: <OF6E64004E.2C5F470C-ON85256D77.00183F7E-85256D77.00490B43@us.ibm.com>
"Julian Reschke" <julian.reschke@gmx.de> wrote on 07/20/2003 12:18:01 PM:

> > From: Geoffrey M Clemm
> >
> > How about the following alternative:
> >
> > For PROPFIND, define a new 208 status code that means "resource 
> > reported".
> >
> > A server that detects a loop in a PROPFIND result, would use 208 
> > code for the 2'nd (and subsequent) encounters with a given resource. 
> > allows
> > the client to reconstruct the binding structure based on just a single
> > PROPFIND call.

> OK, this issue has been coming up several times (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0081.html> 
> the last time).
> 1) Can we get rid of 506 (loop detected)? No, we can't. 506 can occur as
> result of operations other than PROPFIND, for instance COPY.

I agree that we need the 506 for methods that want to just fail the 
The 208 was for operations like PROPFIND, that do not want to fail, but 
to give an accurate report while avoiding the infinite loop.

> 2) What error condition do we need to really indicate for the documented
> example (PROPFIND depth infinity)? The problem is not with the resource
> itself or a specific binding to it. In fact, a PROPFIND depth:1 wouldn't
> indicate any special condition at all. The problem occurs *only* because
> there's a bind loop, yet the request asked for a depth: infinity 
> listing. So there's not a specific resource that can be "blamed" -- 
> it's the traversal of the collection's children that can't be done, and 
> which optimally the response should indicate failure.

There is no error.  We just need to provide a way for the server to convey 
the client that there is a loop.

> 3) A similar problem exists with PROPFINDing deph != 0 on collections 
> access privileges forbid listing the members.

That can be handled by the appropriate status on the appropriate members.
> 4) Will clients that aren't aware of the ordering protocol ignore 
> with a status of 208? Not necessarily -- there may be clients that 
> all 2xx status codes as success (and I think those a stricly conforming 
> RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or 
> we do use it, we can simply use the approach outlined in

I believe the protocol should be designed to produce good behavior to a
client that understands the protocol, and reasonable behavior for a client 
does not.  I believe the 208 will produce this result.

> I'm not convinced that a new 2xx status code is a good idea -- one 
> that's much more simpler would be just to forbid depth:infinity 
> collections that contain bind loops and to define an according 
> value.

A server that believes that can chose to just return 506.  But a server 
be allowed to do better than this.

> If we *do* want a new 2xx code, I'd rephrase the status condition. As a
> matter of fact, the issue is *not* that the resource already was 
> In fact, having multiple bindings to the same resource within the same
> PROPFIND result is just fine.

The 208 status code is explicitly designed to allow a server to use it to
minimize the size of the response in this case as well.

> So, I'd propose:
> "208 OK, but children not listed"
> We could then extend the response body to indicate *why* children 
> been traversed:
> DAV:no-bind-loop (recursing below this collection would result in a 
> DAV:need-privileges (you are allowed to see this collection, but not 
> content)> (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html> 
> a proposal how to marshall that).

I see no need for this added complexity.  208 Already Reported handles
both of these cases equally well.

Received on Sunday, 3 August 2003 09:29:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC