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

Re: LDIF parser performance

Kurt D. Zeilenga wrote:
At 02:05 PM 11/23/2006, Howard Chu wrote: 
ldapmodify will accept multiple modifications without a separator in between them. E.g.:

dn: dc=example,dc=com
changetype: modify
add: cn
cn: foo
sn: bar
description: xyzzy 

While the above may adhere to the ABNF, it's nonsense.  The
changetype is modify, so we're representing a modifyRequest.
The modify request contains a single add operation of cn.  Hence,
any provided values must be of cn.  The second and third values
are not of cn.  That's an error.

While some parsers might be liberal in handling this error,
implicitly inserting additional add operations, that behavior
is something authors of LDIF files should not rely on.  There
certainly are parsers that, quite properly, error on such
LDIF input.

RFC 2849 could do with some clarification.  The intent was
to create a one-to-one mapping between LDIF change records
and LDAP update requests.

That's what I figured, but that's clearly not what it does. The code also collapses some things together, which definitely doesn't create a one-to-one mapping. E.g.,

dn: dc=example,dc=com
changetype: modify
add: cn
cn: foo
-
add: cn
cn: bar
-

This should represent two separate update requests, but it gets collapsed into a single one:

add: cn
cn: foo
cn: bar

That's not a big deal for Adds, but there are other cases that are more troublesome. E.g.

dn: dc=example,dc=com
changetype: modify
delete: cn
cn: foo
-
delete: cn
-

In the old code this will yield an incorrect result on the server; only the "cn: foo" value will get deleted instead of the entire cn attribute. This case is handled correctly in the code I just committed, but in most other respects the new code behaves the same as the old.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/