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

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Geoffrey M Clemm
> Sent: Saturday, July 19, 2003 6:02 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Binding loops and PROPFIND clarification needed (was Re: COPY
> and bindings)
>
>
>
> How about the following alternative:
>
> For PROPFIND, define a new 2xx status code that means "resource already
> reported".
>
> A server that detects a loop in a PROPFIND result, would use this new 2xx
> 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.
>
> In particular, we could add the following paragraph to the Binding
> specification:
>
> -----------------------------
>
> 7.1   208 Already Reported
> The 208 (Already Reported) status code can be used inside a DAV:propstat
> response element to indicate that information about the resource has
> already been reported in a previous DAV:propstat element in that response.
> The members of the 208 status resource are omitted from the response.
> For example, consider a PROPFIND request on /Coll (bound to collection C),
> where the members of  /Coll are /Coll/Foo (bound to resource R)
> and /Coll/Bar (bound to collection C).
>
> >> Request:
>
> PROPFIND /Coll/ HTTP/1.1
> Host: www.example.com
> Depth: infinity
> Content-Type: text/xml; charset="utf-8"
> Content-Length: xxx
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propfind xmlns:D="DAV:">
>    <D:prop> <D:displayname/> </D:prop>
> </D:propfind>
>
> >> Response:
>
> HTTP/1.1 207 Multi-Status
> Content-Type: text/xml; charset="utf-8"
> Content-Length: xxx
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:multistatus xmlns:D="DAV:">
>    <D:response>
>       <D:href>http://www.example.com/Coll/</D:href>
>       <D:propstat>
>          <D:prop>
>             <D:displayname>Loop Demo</D:displayname>
>          </D:prop>
>          <D:status>HTTP/1.1 200 OK</D:status>
>       </D:propstat>
>    </D:response>
>    <D:response>
>       <D:href>http://www.example.com/Coll/Foo</D:href>
>       <D:propstat>
>          <D:prop>
>             <D:displayname>Bird Inventory</D:displayname>
>          </D:prop>
>          <D:status>HTTP/1.1 200 OK</D:status>
>       </D:propstat>
>    </D:response>
>    <D:response>
>       <D:href>http://www.example.com/Coll/Bar</D:href>
>       <D:propstat>
>          <D:prop>
>             <D:displayname>Loop Demo</D:displayname>
>          </D:prop>
>          <D:status>HTTP/1.1 208 Already Reported</D:status>
>       </D:propstat>
>    </D:response>
> </D:multistatus>
>
> A client can request the DAV:resourceid property in a PROPFIND request to
> guarantee that they can accurately reconstruct the binding structure of a
> collection with multiple bindings to a single resource.
> -------------------------------------
>
> Cheers,
> Geoff


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.

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.

3) A similar problem exists with PROPFINDing deph != 0 on collections when
access privileges forbid listing the 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'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.

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

Julian


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

Received on Sunday, 20 July 2003 12:18:16 UTC