[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.
p.
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497