Re: Fwd: Error from MOD referral containing spaces

[Chris Palmer <chris.palmer@pobox.com>]

On 04/02/2013 19:34, Philip Guenther wrote:
> 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?

I've just had a quick look at the UnboundID SDK, and it does look much
better than JLDAP. The API is of course rather different, so I will have
to do a test case and then port the program. It's about 7 years old, and
at the time JLDAP seemed a reasonable choice...

> 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.
>

That sounds right to me. A good reason to move away from JLDAP.

Many thanks for the help.

> Philip Guenther