[Date Prev][Date Next]
meta backend returns error to client on filter decoding errors (ITS#2977)
Full_Name: Aleksander Adamowski
OS: Linux 2.4.22 - Fedora Core 1
Submission from: (NULL) (220.127.116.11)
The meta backend returns an error code to the client if there is a filter
decoding error (e.g. filter is malformed).
According to Pierangelo Masarati this violates RFC; bdb backend for example
returns success code and an empty result.
See this thread on OpenLDAP-software mailing list:
This behaviour of meta backend causes problems e.g. with Courier mail server
which cannot operate properly if meta backend is used.
See http://www.openldap.org/lists/openldap-software/200402/msg00357.html for an
example of query which is handled correctly by bdb backend and incorrectly by
meta backend. The filter shown there is incorrectly decoded (extracted from
slapd logs); the original filter was (!(source=*)) and this should be used in
I'm testing this in a setup where bdb backend listens on port 389 and meta
backend listens on port 390, forwarding all queries to the bdb backend. Correct
queries on existing attributes give the same results on both ports, 389 and
Invalid queries differ in the following way:
When I execute the following command, I get all the entries from directory,
which is a correct outcome:
ldapsearch -x -H "ldap://localhost:389" '(!(source=*))'
The result code is 0 (success):
# search result
result: 0 Success
# numResponses: 561
# numEntries: 560
When I execute the following command, I get an error response:
ldapsearch -x -H "ldap://localhost:390" '(!(source=*))'
# search result
result: 32 No such object
# numResponses: 1