[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: commit: ldap/libraries/libldap getdn.c
Stig Venaas wrote:
>
> On Tue, Dec 04, 2001 at 07:11:57PM +0100, Pierangelo Masarati wrote:
> > Done. Now another migration problem arises. The normalization
> > function at present does not uppercase the DN, so all the code
> > that uses strcmp (a lot!) when comparing normalized DNs is broken.
> > There are two solutions:
> > a) tweak the new dn_normalize to make it uppercase the resulting
> > string (already tried, works fine)
> > b) add a dn_match wrapper that calls dnMatch (which on turn uses
> > strcasecmp as a temporary hack), and replace all the strcmp around
> > the code (I started doing this, but it's kinda a nightmare; if
> > we're not going to use dnMatch all around the code, relying on
> > appropriate uniform normalization, I'd prefer solution a).
> >
> > So I'd rather wait for suggestions before I keep on replacing
> > strcmp's all around (adding an extra set of strlen's because
> > dnMatch uses berval's ...)
>
> To me it seems reasonable to tweak dn_normalize. In addition to do
> case folding you should also do Unicode normalization. The old
> dnNormalize() did this using UTF8normalize( val, UTF8_CASEFOLD ).
> You cannot simply use strcmp (you must pay attention to Unicode
> when doing case folding), and if you want to do both Unicode
> normalization and case folding, doing this with UTF8normalize()
> is faster than doing it as separate operations. I don't know much
> about this, but I would guess that one should normalize each
> attribute value in the DN separately depending on the syntax, and
> not do Unicode normalization (or strcmp) on the entire string. But
> maybe it still works and is faster to do it on the entire DN?
I think this will go in between ldap_str2dn and ldap_dn2str inside
the new dnNormalize; this should also be done selectively on the
values of the attributes whose syntax allows UTF-8 data.
We cannot work at the string level because all UTF-8 that is not
plain ascii is already represented as '\' + HEXPAIR; my guess is
we need to implement the schema aware dnNormalize to have UTF-8
normalization in place in an efficient manner, although we have
to deal with the overhead of finding the AttributeDescription of
each ava in the LDAPDN structure. To this purpose we could store
it in the LDAPAVA as well, possibly only if inside the server and
if explicitly required by a flag. Sort of:
typedef struct ldap_ava {
struct berval *la_attr;
+ void *la_attr_private;
struct berval *la_value;
unsigned la_flags;
#define LDAP_AVA_STRING 0x0000U
#define LDAP_AVA_BINARY 0x0001U
#define LDAP_AVA_NONPRINTABLE 0x0002U
} LDAPAVA;
+ #define LDAP_DN_ATTRDESC 0x0200U
Pierangelo.
--
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano |
mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy |
http://www.aero.polimi.it/~masarati