[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: commit: ldap/servers/slapd result.c



Found some more suspect code in result.c:
--- result.c    1999/12/02 04:17:41     1.9
+++ result.c    1999/12/02 12:28:17
@@ -833,7 +833,7 @@

        if( op->o_protocol < LDAP_VERSION3 ) {
                /* save the references for the result */
-               if( *refs == NULL ) {
+               if( *refs != NULL ) {
                        value_add( v2refs, refs );
                }
                return 0;

send_search_reference was never doing anything on V2 referrals because this
test is backwards.

Also, I have a question about trim_refs_urls. In the V2referral document
http://www.umich.edu/~dirsvcs/ldap/doc/other/ldap-ref.html it says that
a referral is an LDAPURL with only the hostport and optionally a DN. Why
does trim_refs_urls cut off the DN? It seems that it should be examining the
referral for further specs (i.e., searching for '?' and truncating there)
but leaving the DN alone. In the case of a subtree search that includes a
referral, this is a problem because the base of the search will be returned
twice.
e.g.
server1
   o=foo
   ou=bit,o=foo
   ou=bad,o=foo -> referral ldap://server2/ou=bad,o=foo

server2
   o=foo
   ou=bad,o=foo

If I do an "ldapsearch -h server1 -b o=foo objectclass=*" I will get
o=foo returned twice, once from server1 and once from server2, because the
actual referral that we returned has been trimmed down to just
"ldap://server2";. This isn't right.