change in python-ldap method?

Joe Little jlittle at
Tue Feb 26 00:38:35 CET 2002

Thoughts at the very end..

On 2/25/02 3:29 PM, "Michael Ströder" <michael at> wrote:

> Joe Little wrote:
>> When it
>> explodes the DN out of my entry, its string result is:
>> "(cn=whois\+\+)"
>> [..]
>> However, even before I explode it, I already see the DN is stored in my res
>> as whois\+\+.
> This is perfectly right. See RFC2253, section 2.4. After reading BNF in
> section 3. you might be convinced that you're best bet is to handle DNs
> as opaque. "+" is used to form multi-valued RDNs.
>> Searching on this DN results in an ldap.FILTER_ERROR: {'desc':
>> 'Bad search filter', 'info': ''}
> Special chars in search filters are a different thing, see RFC2254.
>> whois++ has been in /etc/services for quite some time.
> I remember that there was a discussion about this very topic on one of
> the OpenLDAP lists.
>> So one of two things
>> has happened:
>> 1) python-ldap has changed behavior in some way (whether first pull of data
>> or search filter usage)
>> 2) MigrationTools (used to load up NIS type data to LDAP) from,
>> which fixed certain things associated with + and other symbols, can load
>> data correctly into LDAP with Perl ala PerLDAP and PythonLDAP doesn't
>> support the same.
> 3) The LDAP libs/server requires proper escaping/handling DNs which
> translates to "+" need to be escaped nowadays. The application using
> python-ldap has to be fixed.

What I find odd about this is that the data retrieved using one call to
Python-LDAP cannot be in turn used again to write back. You have to take the
results and always un-escape any characters before calling LDAP methods
again on data? It seems somehow very wrong that one can't use the DN that
LDAP returns with a result to refer to the same entry again. Wouldn't you

> Ciao, Michael.

More information about the python-ldap mailing list