[python-ldap] Ldif parser bug?

[Michael Ströder]

Tobias Diaz Diaz-Chiron wrote:
> I'm working with the ldif parser and I've found this behaviour:
> 
> If the DN is like:
> 
> dn: dc=operator,dc=com
> 
> it works fine, but if we remove the space after the quotes:
> 
> dn:dc=operator,dc=com
> 
> Parsing results in a ugly "referenced before assignment" error. I've
> checked the RFC about LDIF format and it doesn't mention that the space is
> mandatory, so I think the parser should allow this. The solution (I think)
> it's easy: just add an "else" clause at the "_next_key_and_value(self)"
> method just to allow this.
> 
> What do you think?

It seems you're right.

https://tools.ietf.org/html/rfc2849

dn-spec                  = "dn:" (FILL distinguishedName /
                                  ":" FILL base64-distinguishedName)
[..]
FILL                     = *SPACE

https://tools.ietf.org/html/rfc5234#section-3.6
and its pre-predecessor:
https://tools.ietf.org/html/rfc2234#section-3.6

=> *SPACE could also allow zero spaces.

It likely also affects parsing value-spec. Example 2 in RFC 2849 contains such
test data.

Feel free to submit a patch if you really need it. Start with adding the
test-cases to Tests/t_ldif.py which was fortunately contributed by Petr
Viktorin and recently released in 2.4.21.

Which software produces LDIF without the space after the colon?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/6bbbbb2a/attachment.bin>