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

Re: OpenLDAP-2.0 bug: incomplete LDAP_RES_SEARCH_REFERENCE?

"Kurt D. Zeilenga" wrote:

> >In openldap-current/libraries/libldap/result.c I can see:
> >/*
> > * LDAPv3 (RFC2251)
> > *      LDAPResult ::= SEQUENCE {
> > *              resultCode              ENUMERATED { ... },
> > *              matchedDN               LDAPDN,
> > *              errorMessage            LDAPString,
> > *              referral                Referral OPTIONAL
> > *      }
> > *      Referral ::= SEQUENCE OF LDAPURL        (one or more)
> > *      LDAPURL ::= LDAPString                  (limited to URL chars)
> > */
> >
> >It appears that matchedDN is missing in LDAP reference result messages.
> There is no LDAPResult sequence (which a matchedDN is part of) in a
> LDAP SearchResultReference PDU.
> >You can check it yourselves:
> >./ldapsearch -H ldap://ldap.nameflow.net:389 -s one -b 'dc=org, dc=uk'
> >-x 'objectClass=*' ref '*'
> >
> >I was stuck digging in those BER structures in C sources, so I have just
> >traced LDAP messages in my network :-) The only string informationi in
> >these reference result messages is LDAP URL itself.
> Yes:
>         SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
> >Or I'd be
> >happy if anybody can explain me that this is expected behaviour.
> I believe the behavior of search reference results in OpenLDAP
> is consistent with the specification.

Uhm, just checked the RFC. Not 100% consistent, unfirtunately. Yes, there
should not be matched DNs there, but "4.5.3. Continuation References in the
Search Result" says:

   The SearchResultReference is of the same data type as the Referral.
   URLs for servers implementing the LDAP protocol are written according
   to [9].  The <dn> part MUST be present in the URL, with the new target
   object name.  The client MUST use this name in its next request.
   Some servers (e.g. part of a distributed index exchange system) may
   provide a different filter in the URLs of the SearchResultReference.
   If the filter part of the URL is present in an LDAP URL, the client
   MUST use the new filter in its next request to progress the search,
   and if the filter part is absent the client will use again the same
   filter.  Other aspects of the new search request may be the same or
   different as the search which generated the continuation references.

I've got the following entry:
# testref, org, uk
dn: dc=testref, dc=org, dc=uk
objectClass: top
objectClass: dcObject
objectClass: referral
dc: testref
ref: ldap://ldap.nameflow.net:1389

tor:/# ldapsearch -H ldap://ldap.nameflow.net:389 -s one -b 'dc=org, dc=uk'
version: 2

# filter: objectClass=*
# requesting: ALL

# search reference
ref: ldap://alpha.dante.org.uk:389/dc=dante,dc=org,dc=uk

# test, org, uk
dn: dc=test, dc=org, dc=uk
objectClass: top
objectClass: dcObject
dc: test

# search reference
ref: ldap://ldap.nameflow.net:1389

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 1
# numReferences: 2

The last ref should be ldap://ldap.nameflow.net:1389/dc=testref, dc=org,

Returning DNs in continuation references is very important for clients that
wish to continue search themselves...

So now, if this one is a bug, I'd be glad to submit a patch :-)  Please


          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net