Kurt D. Zeilenga wrote:
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
(consider aliases/cross-references/etc.).
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" an!
d!
ref="
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?
No.
In this case, I think ITS#3942,ITS#3944 can be safely closed: the fixes
seem to behave consistently.
Thanks, p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
