directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Assigned: (DIRSERVER-645) Wrong search filter evaluation with AND operator and undefined operands
Date Sun, 06 Aug 2006 17:19:15 GMT
     [ ]

Alex Karasulu reassigned DIRSERVER-645:

    Assignee: Alex Karasulu

> Wrong search filter evaluation with AND operator and undefined operands
> -----------------------------------------------------------------------
>                 Key: DIRSERVER-645
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>         Environment: ApacheDS 1.0 RC 3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Microsoft Windows XP version 5.1 Service Pack 1
> Softerra LDAP Administrator 3.3.1
>            Reporter: Stefan Zoerner
>         Assigned To: Alex Karasulu
>            Priority: Minor
> I have found a defect in filter evaluation of search ops, if expressions evaluate to
"Undefined", and an AND (&) operator is used. 
> From RFC 2251, chapter 4.5.1
> "Thus for example if a server did not recognize the attribute type shoeSize, a filter
of (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12), (shoeSize>=12)
and (shoeSize<=12) would evaluate to Undefined."
> For illustration see this entry
> dn: cn=Kate Bush,dc=example,dc=com
> objectclass: top
> objectclass: person
> cn: Kate Bush
> sn: Bush
> description: a British singer-songwriter with an expressive four-octave voice
> description: one of the most influential female artists of the twentieth century
> The filter (numberOfOctaves=4) should evaluate to undefined (attribute type not recognized
by ApacheDS). The filter (sn=Bush) evaluates to TRUE for the entry above, and
> (|(sn=Bush)(numberOfOctaves=4)) 
> should evaluate to TRUE, because RFC 2251 states
> "A filter of the "or" choice is FALSE if all of the filters in the SET OF evaluate to
FALSE, TRUE if at least one filter is TRUE, and Undefined otherwise."
> Therefore the expected behavior is that the entry is matched by the filter, and found
by a corresponding search operation, which is the case (no issue).
> On the other hand the filter
> (&(sn=Bush)(numberOfOctaves=4)) 
> should evaluate to Undefined for the entry above, because
> "A filter of the "and" choice is TRUE if all the filters in the SET OF evaluate to TRUE,
FALSE if at least one filter is FALSE, and otherwise Undefined."
> Thus the entry cn=Kate... should not be found with an search operation which uses the
filter, because
> "If the filter evaluates to TRUE for a particular entry, then the attributes of that
entry are returned as part of the search result (subject to any applicable access control
restrictions). If the filter evaluates to FALSE or Undefined, then the entry is ignored for
the search."
> But the server returns the result:
> $ ldapsearch -h localhost -p 10389 -b "dc=example,dc=com" -s one "(&(sn=Bush)(numberOfOctaves=4))"
> version: 1
> dn: cn=Kate Bush,dc=example,dc=com
> $
> Note that the two filters
> (numberOfOctaves=4)
> (&(numberOfOctaves=4))
> work -- Kate is not part of the result set.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message