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

Re: (ITS#5456) inaccurate interpretation of LDIF in back perl

uw@o3si.de wrote:
> Full_Name: Uwe Werler
> Version: 2.3.32
> OS: SLES10 SP1 Kernel
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (
> 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
> issue.

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/