After some more reading : RFC 4511, 4.5.1.7
"A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. Examples include: ... - The assertion value is invalid. " Alex Karasulu wrote:
Hi, ApacheDS will normalize filter values before it attempts a search. When it does this some filter values will not normalize if incorrect resulting in an exception. For example the member attribute which should be a distinguishedName may not be properly formulated due to a bad search request. ApacheDS will return an error instead of attempting the search because an exception results when trying to parse and normalize the DN in the NormalizationInterceptor. BTW a completely unrelated error message is returned resultCode: loopDetect (54). We have to step back and ask ourselves if this is the right behavior we want. Most LDAP servers will still attempt the search even with bad values in the filter assertions in which case the search returns with a SUCCESS resultcode yet no entries are returned. Do we want to enable users to toggle this strict requirement in the NormalizationInterceptor with some configuration parameter? Do we want, in addition, to change the default to simply ignore bad assertion values and continue to attempt a search with those bad values? If we're thinking about allowing users to disable schema checking at various levels then I think we need to allow for relaxing filter normalization. Alex
-- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
