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

Re: DN with semicolon does not work

> I think what we really need to do is to make sure that
>         DN_SEPARATOR()
>         NDN_SEPARATOR()
> are only called with normalized DNs.  Once that is done, then
> the difference between these macros is moot.
> I don't think a semi should appear in either a pretty nor a normalized
> DN.  And if truely an arbitrary DN string, then neither macro is safe to
> use.
> Maybe we need to add
>         assert( (c) != ';' )
> in a few places to figure out how ';' are getting through to
> {N}DN_SEPARATOR calls.

I exactly know how they end up there: it is definitely intended; see macro
LDAP_DN_WILLESCAPE_CHAR() in libraries/libldap/getdn.c.  Escaped semis
remain as such in both pretty and normalized form because they were
considered to be harmless if the appropriate DN parsing was to be used. 
In fact, a normalized/pretty DN will never contain a semi as rdn separator
(we don't rebuild DNs that way!).  I vaguely recall there was some debate
at that time, and I was in favour of hexpair escaping ALL the special
chars in normalized DNs, but someone objected that, besides those that
have a special meaning in LDAPv3 for DN structure (',', '+', '\'),
escaping all would have required to make DNs unnecessarily longer and
awkward to read (I was in favour of hexpair escaping non-ascii UTF-8 as
well :)  My point is that it appears that few DN parsing macros in slap.h
are not in sync with the corresponding macros used in DN parsing/string

Actually, there should be no need to assert (c) != ';', because a ';' in a
DN, no matter if pretty or normalized, can only be escaped and takes no
special meaning.  DN_SEPARATOR() really should on test for ',', and
NDN_SEPARATOR() should not be really used at all.


Pierangelo Masarati

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