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: Sunday, August 03, 2003 3:18 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY
> and bindings)
>
>
> ...
>
> > 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.

I really don't care how you call it. The client is asking for a recursive
listing, and the server can't provide it. The *problem* is that recursing
into the collection would lead to an infinite loop, so there's really no
issue with the collection itself.

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

How? If you don't have permission to list the members of a collection, how
do you report it for a PROPFIND depth!=0?

> > 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 believe it has the same problem that you pointed out re: my proposal, in
particular:

"If we handled it the way proposed below, the old clients will just ignore
the new element, and the user will incorrectly conclude that the collection
had no child by that name."

I agree that it's less likely that an old client will treat 208 the same way
as 200, but it's quite possible.

> > 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 can find a way that is actually better. I fear that the 208 proposal
has the same problem as my original proposal, being that old clients may
incorrectly assume that the collection doesn't have children.

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

I see. So you'd also use it for all duplicates, no matter what the depth
parameter was and whether it's collection or not? This is more consistent,
yet it may cause old clients not to display the second binding to a resource
within a collection because it *doesn't* treat 208 as success.

So old clients that treat 208 as success will incorrectly assume that a
collection was empty, while old clients that treat 208 as error will fail to
display additional bindings to a resource.

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

I think not. Actually, I think that there is no easy way to marshall this
information in a way compatible with old clients. We've spent a lot of time
discussing this, but still don't have a solution. Therefore my alternate
proposal just to forbid this very special case.

Julian

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

Received on Monday, 4 August 2003 09:21:21 UTC