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

[quanah@stanford.edu]

--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?  I've 
added cn's with all sorts of spacing, and they did not end up encoded in 
the cn attribute.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html