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.
> 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
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.,
This should represent two separate update requests, but it gets
collapsed into a single one:
That's not a big deal for Adds, but there are other cases that are more
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/