directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject DN, escaping, values and prepareString
Date Mon, 22 Feb 2016 20:55:08 GMT
Hi guys,

I'm in the train back to Paris, where I have little to do but reading
the RFCs (4514, 4518, 4512).

When I implemented the 'String Preparation' RFC (4518), I assumed it
would save a hell lot of CPU to do it once and for all, and to store the
result in the Values stored in the backend. The rational being that it's
a costly operation, and there is no mean to do it over and over for
Values we have already processed.

The problem being that we are mixing two concepts here : normalization
and string preparation. String preparation is intended to be used only
when applying a matching rule. Normalization is the process of
transforming a Value to something consistent, removing spurious spaces,
using lower case if the AttributeType is case insensitive, etc. In the
mean time, DN processing, especially conversion from ASN.1 to String and
from String to DN requires a different processing, where we fist
fragment the DN into AVAs, and then we normalize/prepare the values.

Note that the two operations aren't exclusive : when comparing two DNs,
we end with comparing values, thus string preparation is still required.

Enters the filter processing (RFC 4515). Different escaping, still
needing a string preparation. And there is a specific treatment for
inner spaces i order to match some special filters (like cn=foo\20*\20bar).

Now, we are in trouble... If we decide to desactivate the string
preparation, to only apply it to any value we process when a matching
rule is at play, we lose a lot of performance (OTOH, we gain a lot on
every addition or update). If we decide to keep it, we have to review
the way we use it, escpecially when processing DNs. The last nail in the
cuffin : most of the time, we don't need to go through the prepare
string operation on the client (except when comparing two values,
something that is not frequently done), but we do it anyway because the
client API and the server API is the same.

I'll sleep on that and give you baxk some more thoughs in the next few days.

Thanks !



Mime
View raw message