[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: DN with semicolon does not work

> 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.  I used this trick
for different representations of the same DN.

>>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.
> Yes.
> 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
> LDAPv3.

OK, I'll carve the test for this.


Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497