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