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.