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

"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 
already
> > reported".
> >
> > A server that detects a loop in a PROPFIND result, would use 208 
status
> > code for the 2'nd (and subsequent) encounters with a given resource. 
This
> > 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> 
for
> 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 
request.
The 208 was for operations like PROPFIND, that do not want to fail, but 
want
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 
resource
> listing. So there's not a specific resource that can be "blamed" -- 
instead,
> it's the traversal of the collection's children that can't be done, and 
for
> which optimally the response should indicate failure.

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

> 3) A similar problem exists with PROPFINDing deph != 0 on collections 
when
> 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 
resources
> with a status of 208? Not necessarily -- there may be clients that 
accept
> all 2xx status codes as success (and I think those a stricly conforming 
to
> RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or 
if
> we do use it, we can simply use the approach outlined in
> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html>.

I believe the protocol should be designed to produce good behavior to a
client that understands the protocol, and reasonable behavior for a client 
that
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 
approach
> that's much more simpler would be just to forbid depth:infinity 
PROPFINDs on
> collections that contain bind loops and to define an according 
precondition
> value.

A server that believes that can chose to just return 506.  But a server 
should
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 
reported!
> 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 
haven't
> been traversed:
> 
> DAV:no-bind-loop (recursing below this collection would result in a 
loop)
> DAV:need-privileges (you are allowed to see this collection, but not 
it's
> content)> (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html> 
for
> a proposal how to marshall that).

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

Cheers,
Geoff