On 5 Apr 2008, at 19:15, Quanah Gibson-Mount wrote: > --On Friday, April 04, 2008 6:07 PM -0500 Graham Barr > <gbarr@pobox.com> wrote: > >> Begin forwarded message: >>> Transaction: Ticket created by Uwe.Werler@o3si.de >>> Queue: perl-ldap >>> Subject: suggestion for the position of CR character in >>> Net::LDAP::LDIF entry >>> Broken in: (no value) >>> Severity: (no value) >>> Owner: Nobody >>> Requestors: Uwe.Werler@o3si.de >>> Status: new >>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34689 > >>> >>> >>> Hello, >>> >>> after some testing and playing around with Net::LDAP::LDIF and the >>> back_perl "database" from OpenLDAP I found that some entries will >>> not be >>> accepted by the latter if I use an entry (or a list of them) >>> produced by >>> the LDIF module. The cause of this is the "CR" at the beginning of >>> each >>> entry/DN and the missing empty line at the end. >>> >>> I know that this doesn't break RFC2849 and so is not the problem of >>> Net::LDAP::LDIF. But for compatibility reasons I suggest to print >>> the >>> "\n" character not before but after each entry. This produces the >>> same >>> output as by ldapsearch and will be accepted by the perl backend >>> from >>> OpenLDAP. >> >> Anyone see any issue with doing this? > > Just to note, the perl backend of OpenLDAP is RFC compliant. > > See Uwe's ITS at <http://www.openldap.org/its/index.cgi/? > findid=5456> and the follow up. > > It looks like this is due to a bug in Net::LDAP::LDIF. Are you sure? The ABNF in RFC 2849 says SEP is *before* each ldif- attrval-record. As long as each attrval-spec is ended by a SEP (which it seems to be) then I think there should be no extra SEP before the end of file. Cheers, ChrisThread Previous | Thread Next