> Well, I don't know if it has to be considered as a bug (failure ?
> feature request ?). Because the comment in the code does say :
> * XXXmcs: we don't support scope or filters in search referrals yet,
> * so if either were present we return an error which is probably
> * better than just ignoring the extra info.
> So Mozilla behaves correctly regarding to this limitation. It does
> supports referrals, *except* with LDAP URLs which contain a scope or a
> If you think this a truly a bug, please do so.
I think it is a bug, or at least a lapse of LDAPv3 support - see
http://www.ietf.org/rfc/rfc2251.txt sections 4.1.11 and 4.5.3.
"Some servers (e.g. participating in distributed indexing) may provide a
different filter in a referral for a search operation. If the filter
part of the URL is present in an LDAPURL, the client MUST use this
filter in its next request to progress this search, and if it is not
present the client MUST use the same filter as it used for that search.
Other aspects of the new request may be the same or different as the
request which generated the referral."
So it seems as though we should honor the new filter. It doesn't say
whether or not the new scope should be honored. I suppose there are
several ways we could handle this:
1) Leave scope handling as is - return an error
2) Ignore the scope and just use the same scope as in the original
3) Honor the scope
I prefer 3 - if a new scope is present, it's there for a reason and
should be respected. We could add another LDAP option for this so you
would be able to choose the 1, 2, or 3 behavior.