[Date Prev][Date Next]
Re: Back-ldap and matchedDN (Was: (ITS#3942))
Kurt D. Zeilenga wrote:
In this case, I think ITS#3942,ITS#3944 can be safely closed: the fixes
seem to behave consistently.
It's my view that matchedDN can be returned anytime its useful,
regardless of what the resultCode might be. The value indicates
the most-subordinate object used in finding the target/base
object. It can even be useful when the resultCode is success
At 03:00 PM 8/17/2005, Pierangelo Masarati wrote:
I note that now back-ldap, as a consequence of retaining anything comes from ldap_parse_result(), in case it hits a referral it returns bot the ref and the matchedDN. For example, in test039, there is a referral entry "cn=Somewhere,ou=Meta,o=Example,c=US". According to draft-ietf-ldapbis-protocol, the matchedDN can should be returned with some specific errors, but could be returned also with other errors/return codes, I guess including referral return codes. When searching for, e.g. "cn=Deeper,cn=Somewhere,ou=Meta,o=Example,c=US", back-ldap returns a matchedDN="cn=Somewhere,ou=Meta,o=Example,c=US" and a ref="ldap:///cn=Deeper,cn=Somewhere,ou=Meta,o=Example,c=US". In this case, the matchedDN might make sense, because the ref indicates how to continue the operation, while the matchedDN indicates what portion of the DN was present locally. But when searching exactly for "cn=Somewhere,ou=Meta,o=Example,c=US" one gets both matchedDN="cn=Somewhere,ou=Meta,o=Example,c=US" and!
ldap:///cn=Somewhere,ou=Meta,o=Example,c=US". I suspect in this latter case the matchedDN is definitely redundant.
No, because it advises the client that the server had specific
knowledge at cn=Somewhere,ou=Meta,o=Example,c=US. WIthout this,
the client might think the referral was due to global knowledge.
Should it be trimmed?
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497