[Date Prev][Date Next]
Re: (ITS#5456) inaccurate interpretation of LDIF in back perl
> Full_Name: Uwe Werler
> Version: 2.3.32
> OS: SLES10 SP1 Kernel 22.214.171.124-0.2.3-xen
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (126.96.36.199)
> The database backend "back_perl" expects LDIF entries beginning with "dn:" and
> ending with an empty line. RFC2849 only describes that an entry is everything
> except an empty line and a line not beginning (after a CR/LF) with a single
> white space character.
Wrong. The grammar in RFC2849 quite explicitly states:
ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-changes = version-spec 1*(1*SEP ldif-change-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
ldif-change-record = dn-spec SEP *control changerecord
That means an LDIF file must start with 0 or 1 version-specs, then a dn-spec.
And, all records must end with LF or CR/LF.
> After some testing with back_perl I noticed that the LDIF entries produced by
> the perl module Net::LDAP::LDIF were not acceptet because they are beginning
> with an empty line and ending only with a simple CR charakter.
> This behavior breaks RFC2849. After changing LDIF.pm from that module to produce
> the CR after the entry back_perl accepts this entries too.
> IMHO this is a misbehavior so I'm very glad if You'll take a look at this
Apparently it Net::LDAP::LDIF is broken. Since that is not a piece of OpenLDAP
Software I don't see what we can do about it. This ITS will be closed. Contact
the author of Net::LDAP::LDIF to pursue this further.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/