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

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 3 Aug 2003 09:17:49 -0400

"Julian Reschke" <[email-masked]> 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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 4 Aug 2003 14:52:26 +0200

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Geoffrey M Clemm
> Sent: Sunday, August 03, 2003 3:18 PM
> To: [email-masked]
> Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY
> and bindings)
>
>
> ...
>
resource
instead,
for
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.

when
> 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?

resources
accept
to
if
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.

approach
PROPFINDs on
precondition
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.

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

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

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 4 Aug 2003 11:39:40 -0400

"Julian Reschke" <[email-masked]> wrote on 08/04/2003 08:52:26 AM:

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

My counter proposal is that servers who are concerned about this can
return 506 on the request as a whole, while servers that are not
concerned about old client behavior in this regard can take advantage
of 208.

Cheers,
Geoff

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 4 Aug 2003 09:43:03 -0700

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

The client is asking for a recursive listing? That's one way to look at it.
Another way to look at it is that the client is asking for a listing of a
finite set of resources, and the specification can decide how to
successfully return properties of those resources in presence of loops.  It
serves no purpose for the client to get an infinite set of properties nor
does it want them.  So as we're defining what the behavior of
PROPFIND-depth-infinity is in the presence of loops, we can define what the
client "asks for" too, according to what we think the requirements are.

I agreed with your arguments about how existing clients might react to a new
status code.  I suspect that the way existing clients respond to a supposed
success (2xx) will be more interoperable than the way they will respond to a
supposed failure (4xx, 5xx).

Lisa

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 4 Aug 2003 09:53:33 -0700

Let's not encourage servers behave differently unless that's really
necessary.  Clients that *do* support bindings, in particular, should be
able to count on servers handling this case in predictable ways.
 
lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Geoffrey M Clemm
Sent: Monday, August 04, 2003 8:40 AM
To: [email-masked]
Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY
and bindings)

Cheers, 
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 4 Aug 2003 22:52:20 +0200

> Sent: Monday, August 04, 2003 5:40 PM
> To: [email-masked]

OK, but let's please be clear about what we're doing. Both your "208"
proposal and my old proposal suffer from old clients possibly
misinterpreting the response. In general, a server has no way to know what a
client will understand, so -- as Lisa just pointed out -- we really
shouldn't send possibly misleading information to the client.

But fortunately, this can be fixed:

1) For PROPFIND/depth:infinity on a collection containing bind loops, always
return 506 *unless* the client clearly indicates that it knows about the
protocol extension.

2) Extend PROPFIND such that the client can indicate that it knows about our
new-style responses, such as:

<propfind xmlns="DAV:"><allprop/><understand-208/></propfind>

This would settle the issue about not confusing old clients. We thus would
have the freedom to express the "new" conditions we want to marshall. There
seem to be two approaches:

a) (your 208 proposal): allow the server just to report a 208 for a resource
that was already mentioned in the response. A smart client would need to
PROPFIND DAV:resource-id to actually process these, but that's easy enough.

b) (my proposal): allow the server to indicate somehow that the resource was
reported ok, but members were omitted from the result. I like this one more
because it would also resolve the other issue (PROPFIND not being able to
report that the client didn't have the *right* to list the members of a
collection -- I think you missed this one from my previous reply).

Regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 4 Aug 2003 17:46:57 -0400

Since this statement of "what protocol extensions I understand" is
a generically interesting one, including for requests that do not have
an extensible body (e.g. PUT), I suggest we marshall this information
in the form of a header, not as an XML tag in the body of the request.

Other than that, your proposal is fine with me.  This is clearly something
which should eventually find its way into a successor of 2518, but I'm
happy to introduce it in the binding protocol first.

I'd like to see more folks comment on this though, before moving in that
direction.

WRT to the 208 approach vs. the alternative you described, I believe that
the 208 approach is the simplest approach, and I do not think
it is a benefit to try to couple two very different kinds of situations, 
i.e. how
to marshall a recursive structure vs. how to report on an access 
restriction.

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 5 Aug 2003 09:30:38 +0200

> Sent: Monday, August 04, 2003 11:47 PM
> To: [email-masked]

Yes and no. As you say, using headers has the advantage to work with PUT.
However, I'd like to avoid adding headers because of the namespacing
problems. If we go down that road, we really should adopt an extensible
scheme, such as the HTTP Extension Framework (RFC2774).

i.e. how
> to marshall a recursive structure vs. how to report on an access

OK, here'a proposal: add a DAV:response-format element to DAV:propfind.
Members of DAV:response-format indicate that the client is prepared to
process particular response formats that are not strictly compatible tp
RFC2518. In this case, a client would submit

<propfind xmlns="DAV:">
  <response-format><process-208/></response-format>
  <allprop/>
</propfind>

(I'd like to be able to re-use that for other extensions, therefore a
container element seems to be a good idea).

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 5 Aug 2003 14:19:35 -0400

I think the granularity of <process-208> is too fine.
I'd prefer to just allow the use of the DAV header as a request header,
and if the client says:

PROPFIND
DAV: 1,2,bind

and then the server can use 208 responses (i.e. because "bind" appears
in the request DAV header).

Or if the request header should have its own name, use something like
a "DAV-CLIENT" header.

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 5 Aug 2003 20:53:11 +0200

> Sent: Tuesday, August 05, 2003 8:20 PM
> To: [email-masked]

Well, we could choose a different name and make it less granular if you
prefer that.

> in the request DAV header).

I dislike inventing new headers, but in fact that wouldn't be a new header.
So we would define that clients can claim compatibility to a specific DAV
feature by sending the header. In this particular case, we'd still need to
define what "bind" means when it appears in a "DAV" header, because
currently the draft doesn't.

> Or if the request header should have its own name, use something like

Let's try to avoid that.

I'd like to state again why I prefer to marshall this in the request body:
we don't need to think about what the header means for methods other than
PROPFIND, and we can use the same extension mechanism to fix another issue
RFC2518/ACL altready has (not being able to marshall information about the
fact that the content of a collection couldn't be listed).

Julian