[python-ldap] Ldif parser bug?
michael at stroeder.com
Wed Sep 30 13:08:06 CEST 2015
Michael Ströder wrote:
> Petr Spacek wrote:
>> On 30.9.2015 10:30, Michael Ströder wrote:
>>> Tobias Diaz Diaz-Chiron wrote:
>>>> Ok, thank you... I'm working on that...
>>>> My LDIF is obtained from a telecom server that send users data in ldif
>>>> format. In the ldif some DNs has spaces and some not...
>>> Thinking about this FILL some more I wonder how leading spaces in attribute
>>> values shall be handled. This might get complex and I'm a bit concerned of
>>> interop issues.
>>> First try to fix your specific case in LDIFParser._next_key_and_value()
>>> probably a *appending* another specific elif clause.
>> I do not have reference to spec at hand but I believe that all values starting
>> or ending with whitespace should be base64-encoded to avoid ambiguity.
> Unfortunately it's not that clear.
> From RFC 2849:
> 8) Values or distinguished names that end with SPACE SHOULD be
> base-64 encoded.
> This is only a SHOULD and AFAICS it says nothing about leading spaces. So
> handling *SPACE as 0 or more space chars would require an lstrip() when
> extracting the attribute value after colon. But this might not meet the
> expectation of some LDIF producers trying to encode leading space(s) like this:
> foo: bar
> And even this will be ambigous:
> foo: bar
Hopefully other implementors respond to this:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
More information about the python-ldap