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/