Yeah good point. So we can mark it as undefined or follow the procedure for just removing the AVA from the filter.
Alex On Nov 15, 2007 4:57 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > 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 > > >
