Re: add,modify rules not consistent (ITS#3138)

[Kurt@OpenLDAP.org]

I did a similar test using OPENLDAP_REL_ENG_2_2 (which should be
consistent with 2.2.11 in this area).

replace: sn
sn:: bWFqb3iq
sn:: IG1ham9y

and got
  ldap_modify: Type or value exists (20)
    additional info: sn: value #0 provided more than once

Are you sure you're not trying to do?

replace: sn
sn: bWFqb3iq
sn: IG1ham9y

(note the ':' instead of '::')


At 02:52 PM 5/10/2004, Quanah Gibson-Mount wrote:


>--On Monday, May 10, 2004 1:15 PM -0700 "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:
>
>>At 09:56 AM 5/10/2004, quanah@stanford.edu wrote:
>>>Full_Name: Quanah Gibson-Mount
>>>Version: 2.2.11
>>>OS: Solaris 8
>>>URL: ftp://ftp.openldap.org/incoming/
>>>Submission from: (NULL) (171.66.182.82)
>>>
>>>
>>>This weekend we encountered behavior in openldap that made it hard for
>>>us to debug what was happening in our program.
>>>
>>>We found that there are times when ADD's will reject (multiple values of
>>>the same CN provided) when MOD's will not (it accepts the change no
>>>complaint) for the same entry.  Obviously, in case (1), the entry was
>>>deleted and then ADD'd, and in case (2) the entry already existed, and
>>>we were replacing CN (but just to be clear. ;) ).
>>>
>>>The values in question in this case were the non-MIME 64 encoded
>>>versions of:
>>>
>>>cn:: bWFqb3Ig
>>>cn:: IG1ham9y
>>>
>>>I believe that progamatically, there are "NULL"s encoded in the cn (that
>>>was the bug in our program).
>>
>>Actually, they differ by leading/trailing space (U+20) characters
>>
>>6d 61 6a 6f 72 20                                 |major |
>>20 6d 61 6a 6f 72                                 | major|
>>
>>These values are equivalent and hence both the add and modify should fail.
>>Are you seeing differences between modify/add and modify/replace?
>
>Yes.  Adding the entry when it doesn't exist in the DB fails.  Doing a modify to replace the CN's when the entry already exists works.
>
>Also, why would spaces in the entry cause it to be Mime encoded?

For clarity, s/Mime/Base64/.

See RFC 2849, notes 4 and 8.

>I've added cn's with all sorts of spacing, and they did not end up encoded in the cn attribute.

Not all LDAP values require base64 encoding when presented as LDIF.
(Note that LDIF is just a intermediate format, the actual value is
LDAP is not affected by use of base64 in LDIF.