[Date Prev][Date Next]
Re: DN with semicolon does not work
At 01:45 PM 5/7/2004, Pierangelo Masarati wrote:
>> 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
>> DB representations).
>OK, then I'll patch 2.2. differently, if it can be easily
>accomplished. In this case, the DN_SEPARATOR() change
>already in place in hEAD should suffice.
>>>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.
>Yes, but then I couldn't test invalid DNs because the
>whole operation would have failed.
You could use individual modify/add for each case, all
against one entry.
>>>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
>OK, I'll carve the test for this.
I meant, yes, LDAPv2 is moot. No need to do any LDAPv2
specific slapd(8) testing, slapd(8) doesn't talk LDAPv2.
(It talks a subset of LDAPv3 when v2 is requested.)
> SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497