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

Re: LDIF parser performance

At 09:19 AM 11/24/2006, Howard Chu wrote:
>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.

In some cases, the parser can be said to liberal in what it accepts.
In some cases, the parser is simply broken.

Kurt