[Date Prev][Date Next]
Re: DN with semicolon does not work
At 01:23 PM 5/7/2004, Pierangelo Masarati wrote:
>> Okay, I think "1\2C2\3B" is easier to read than "1\2C2\;3".
>> The latter requires me to recognize and understand two
>> different escaping methods instead of just one.
>Fine. I note that right now normalized and pretty DN are
>exactly the same (same flag is passed to DN parsing/stringifying
>routines); all we need to do is add the special chars to the
>mcros that decide if they have to be escaped as chars or
>hexpairs. I note that this part of code has been already mucked
>with by defining the PRETTY_ESCAPE macro at the beginning of
>library/libldap/getdn.c; I guess that if we simply undefine it,
>we get hexpair escaping of all specials.
I suggest we do that for HEAD. For RE2.2, we should fix the
bug but leave the normalized form alone (don't want to change
>I've just committed an essential DN write test, based on your
>draft. Unfortunately, the first thing this did was to reveal
>that back-bdb's ITS#3063 (empty suffix) bug is still there;
>now, instead of a sigsegv we get that only one entry can be
>added to the database.
I note that you could implement the test using the
member attribute of a group... then you'd only hve
to do one add and one search.
>So, the test currenlty works only with ldbm.
>Another issue is that currently slapd considers most of the LDAPv2
>syntaxes invalid (e.g. "<DN>", "RDN;RDN;RDN", "OID.1.2.3=value"
>and so) because the DN parse routines don't get passed the
>LDAPv2 ccompatibility flag. I think this was done on purpose,
>so the ';' as rdn separator is now really a moot point.
At present, we don't claim to support LDAPv2 as specified
in RFC 1777. When a v2 bind is requested, we (like most
other implementations) instead limit LDAP to a subset of