[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP Referrals
On Thu, 30 Mar 2000, Howard Chu wrote:
> > 2. If you set the base DN of a query to a subtree which *DOESN'T*
> > contain a
> > referral, the referral is *still* generated and the slave slapd still gets
> > queried. I must admit this was not what I expected!
>
> Not sure what you mean. Perhaps you should provide an example.
Ok, assume the following tree:
root
|
common
/ \
partA partB
/ \
... ...
If you store root, common and partA in server A and partB in server B and then
insert a referral entry for partB into server A, the following happens (all
searches submitted to server A):
1. A subtree query with a base of "root" or "common,root" will check the partA
subtree and generate a referral to server B for the partB subtree. This is
what you would expect.
2. A one-level query with a base set to "partA,common,root" will *only* check
server A. Again, this is what you would expect.
3. A one-level query with a base set to "partB,common,root" *won't* generate a
referral, instead you are told that it matched up to the "common,root" part of
the DN. I'm not entirely sure that this is what I would expect to happen, but
the documentation for V2 does imply that referrals are only generated for
subtree searches so I'm happy with this action.
4. If you issue a subtree query with a base of "partA,common,root", server A
checks the "partA" subtree as you would expect, *but* it also returns a
referral. Given that the referral entry is *outside* the scope of the search
this is not what I would expect to happen at all!! Can anyone reassure me - or
explain why this occurs?!
> This is not defined in the V3 protocol. Obviously if the server is going to
> contact a remote server on behalf of a client, the client never sees that a
> referral took place.
I figured that would be the case. I've taken a look at your back-ldap code and
it's certainly an option I'm considering. I may well look at making a few
additions to the code to add some local result caching as well as connection
pooling to reduce the number of connect/bind operations in high-load scenarios.
Cheers,
Neil
-------------------------------------------------------------------------------
Neil Hunter Tel: +44 (0)113 234 6073
Internet Systems Developer Fax: +44 (0)113 234 6065
Planet Online Limited Mobile: +44 (0)7787 100 649
-------------------------------------------------------------------------------