Re: Fwd: Error from MOD referral containing spaces

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Monday, February 04, 2013 11:55 AM +0000 Chris Palmer 
<chris.palmer@pobox.com> wrote:

> I am having trouble processing referred MOD requests where the DN
> contains spaces. It always fails with error 32 (not found).
>
> Instance A is the master.
> Instance B is a replica, type refreshAndPersist, and contains "updateref
> ldap://instanceA:389"; following the syncrepl.
> Both A and B are openldap 2.4.33 with identical configuration apart from
> the sync and referral settings.
>
> Updates to A replicate immediately and correctly to B (including those
> with spaces in the DN).
> Updates to B, without spaces in the DN, are referred to A, processed
> correctly on A, and replicated correctly to B.
>
> 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?

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration