On Mon, 4 Feb 2013, Quanah Gibson-Mount wrote:
--On Monday, February 04, 2013 11:55 AM +0000 Chris Palmer chris.palmer@pobox.com wrote:
...
But: updates to B, *with* spaces in the DN, are referred to A where they fail with error 32. The client (using Novell jldap 2009.10.07) does not report an error, and of course the change is not replicated.
The MOD to B appears in ldap.log as dn="cn=first second,ou=.......". Note the space between the two words of the CN. (This is also how MODs sent directly to A appear, which do get correctly processed).
A network trace shows B generating a referral to A of the form: ldap://instanceA:389/cn=first%20second,ou=.....
The MOD referral to A appears in A's ldap.log as dn="cn=first%20second,ou=....." with err=32.
I'm at a loss to know where to go from here, or even which component is at fault. Can anyone help?
Well, %20 is just the space encoded, which I would think would be OK. Do you hit the same issue if you use UnboundID's SDK rather than JLDAP?
It sounds to me like OpenLDAP is returning the correct URL in the referral, but when Novell's jldap processes the referral it is failing to decode the percent-encoding when generating the new request to the referred-to server, as percent-encoding is not used (of course) in DN field of the actual LDAP request.
Philip Guenther