Description: ------------ Per RFC2849, page 5, Note 2, "When joining folded lines, exactly one space character at the beginning of each continued line must be discarded." File LDIF.php does not do this because it calls trim() which removes many spaces, not "exactly one space" per the spec. I will demonstrate using this valid LDIF: dn: cn=123.45.6.7,cn=Clients,cn=LDAPv3 Service Config,ou=DHCP Config,o=Rutgers OIT,c=US objectClass: top objectClass: dhcpHost cn: 123.45.6.7 dhcpStatements: fixed-address 123.45.6.7 dhcpHWAddress: ethernet 00:11:22:33:44:55 please note the two leading spaces on line 2 -- " OIT,c=US" on said line. Test script: --------------- <?php require 'LDAP2.php'; $options = array('onerror' => 'die'); $entries = array(); $ldif = new Net_LDAP2_LDIF('example.ldif', 'r', $options); do { $entry = $ldif->read_entry(); $dn = $entry->dn(); echo "$dn\n"; } while (!$ldif->eof()); $ldif->done(); ?> Expected result: ---------------- I would expect "cn=123.45.6.7,cn=Clients,cn=LDAPv3 Service Config,ou=DHCP Config,o=Rutgers OIT,c=US" as output. (Note the space in "Rutgers OIT" string.) Actual result: -------------- Actual current result is: cn=123.45.6.7,cn=Clients,cn=LDAPv3 Service Config,ou=DHCP Config,o=RutgersOIT,c=US SOLUTION: The preg_match on line 690 already accounts for this (sort of -- technically it is matching \s which is more liberal than the RFC). However, the leading space will not be in $matches[1]; this is handled before the data enters $matches[1]. As such it may be used directly. If you are concerned over cut and paste errors, at a minimum please use rtrim()? PATCH, tested with tests/Net_LDAP2_LDIFTest.php successfully: --- LDAP2.trim/LDIF.php 2010-01-21 23:21:40.000000000 -0500 +++ LDAP2.notrim/LDIF.php 2010-01-21 23:21:50.000000000 -0500 @@ -695,7 +695,7 @@ $this->dropError('Net_LDAP2_LDIF error: illegal wrapping at input line '.$this->_input_line, $this->_input_line); } else { $last = array_pop($this->_lines_next); - $last = $last.trim($matches[1]); + $last = $last.$matches[1]; $this->_lines_next[] = $last; $datalines_read++; }

Thank you very much for your detailed bug report and also the attached patch. I will test that case and imlpement the code for the next release.

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Fixed in revision 294038. Again, thank you!