[moved to -devel for discussion]
On Fri, 2005-09-30 at 18:39 +0000, raphael.ouazana@linagora.com wrote:
Finally I think it is a configuration problem : a special case of
recursive referral.
I think you can close this ITS or change it in a feature request to detect
this special bad configuration :
Server 1 with back-ldap pointing to server 2.
Server 2 with back-bdb with a referral to server1.
I think we need to design some procedure to detect this type of issues.
In fact, now that back-ldap is being used for a number of applications
that may give rise to circular referral conditions (proxy, chain, ...),
the referral mechanism appears somewhat inadequate. In fact, it doesn't
allow a built-in and standardized way to keep track of its history
and/or at least count. While this might be food for thought for the
ldapbis list, the current implementation of the proxy and of the chain
overlay would really need this. For example, the current implementation
of the chain overlay violates draft-ietf-ldapbis-protocol where it
states
Clients that follow referrals MUST ensure that they do not loop
between servers. They MUST NOT repeatedly contact the same server for
the same request with the same parameters. Some clients use a counter
that is incremented each time referral handling occurs for an
operation, and these kinds of clients MUST be able to handle at least
ten nested referrals while progressing the operation.
because in this case it is __not__ the client library that follows
referrals and counts the number of referrals that have been followed
(thus limiting recursion by limiting the maximal count of referrals
chased, instead of keeping track of the values that were chased). With
back-ldap and with proxies in general, there is no way to determine if a
request comes as a consequence of a referral chasing.
Maybe we could add some sort of control that appends a cookie to
requests and instructs the server to propagate that cookie when chasing
referrals or proxying the request. The appearance of the cookie in a
request to a server, when the cookie originated from that server for
that very request, would indicate a circular reference. I think there
is more to think about this (servers that do not implement this control
would destroy its usefulness; we need a specific control to implement
something that should be granted anyway according to draft-ietf-ldapbis-
protocol; each sub-request performed to satisfy the initial one would
need to be appended to the cookie because the circular reference may
start at any level of nested request; ...).