From: Chris R. <chr...@ma...> - 2003-01-11 08:36:18
|
On 10/1/03 8:14 pm, Kurt D. Zeilenga <Kurt@OpenLDAP.org> wrote: > At 01:51 AM 1/10/2003, Chris Ridd wrote: >> I don't think that's a valid search filter in LDAP (you can empty '&' >> filters in DAP if I recall), > > LDAPv2 actually allowed empty AND/OR sets on the wire > yet the LDAPv2 filter string representation was > defined such that one element was required. When > LDAPv3 was defined, instead of correcting the string > representation to allow empty sets, a restriction > was placed upon the protocol. This is unfortunate > as now clients have no standard way to assert absolute > truth or absolute false. I hadn't looked as far back as LDAPv2 :-) You're right though, there does sometimes need to be a way to have a filter which is always true or false. >> Try a filter of "(objectclass=*)" instead, as this will normally match every >> entry. > > Yes, ***normally***. There are cases where (objectClass=*) > may evaluate to False (or Undefined and, hence, treated as > False). Indeed. Access controls might prevent the filter match, there may not *be* an objectclass in the object (like in a DSE), that kind of thing. > A number of LDAP servers however do support assertions > with empty AND/OR sets. For example, OpenLDAP 2.1. > Because this feature is considered generally useful, I've > written draft-zeilenga-ldap-t-f to (re)introduce them > back into LDAP as an extension. Obviously the string representation of search filters document needs updating too; the BNF I posted from 2252 doesn't permit empty AND/OR sets (ie filterlist = 1*filter) Cheers, Chris |