My investigation started because we were testing searches through dish, such
as "sn={T.61}*harris". And assume that whether or not the entry, ending
with "harris", had a T.61 character in the beginning, it should return a
match on the search. (Correct me if I am wrong on that assumption.) But the
search came back with "search failed to find anything". When I did the
search without the {T.61}, (sn=*harris), it returned 3 matches. When
running dish with -pdus option, I could see that the dish code was not
creating the PDU correctly, when doing "sn={T.61}*harris". The PDU was
generated as:
...
UNIV SEQ
(CONT 0x0 (UNIV T61S 0x0))
(CONT 0x2 (UNIV PRTS 0x6 "harris"))
which indicated a zero length T.61 initial string. This would cause the log
message in the dua.log as:
character '{' not in printable string
auto-convert to T.61 for '{T.61}harris' ('{' not allowed)
and the search to fail. I believe the PDU should reflect something like:
UNIV SEQ
(CONT 0x0 (UNIV T61S 0x6 "harris))
If you look at the dish filteritem.c code it needs to call the str_at2AttrV
that will strip off T.61 header before converting to an Attribute Value.
(*** I can send you diff of the modules if you are interested.)
Then the main problem on the quipu side was that by the time the request
reached the quipu code it had a T61_MARK character ($) in the string that
wasn't being ignored. The tlexequ routine (in string.c) correctly
increments past the T61_MARK, but in turbo_index.c and ds_search.c we were
not calling tlexequ. The problem needed to be handled for all conditions,
initial, any, and final in aux_substr_search (ds_search.c) and in
substring_prefix_case_cmp (turbo_index.c). (***Again I can send you a diff
of the modules.)
I hope this helps.
-francine
----------------------------------------------------------------------------
---
Francine Grimmer
AT&T GIS
email: francine.grimmer@SanDiegoCA.ATTGIS.COM
phone: 619 485-3147
fax: 619 485-2166
----------------------------------------------------------------------------
---
----------
> From: mcs
> To: Roland Hedberg
> Cc: ldap
> Subject: Re: Filter question
> Date: Wed, May 24, 1995 12:05PM
>
> >From: Roland Hedberg <Roland.Hedberg@umdac.umu.se>
> > To: ldap@umich.edu
> > =
>
> > I issue a search for "=C5ke Sandgren"
> > (notice the special swedish character in the beginning, an A with an
rin=
> g
> > above)
> > in a slightly modified version of web500gw, but that has little bearing
> > for this, since it uses standard ldap operations.
> > =
>
> > The filter I see in the DSAs logfile is what I would expect
> > =
>
> > | ((sn=3D{T.61}\caAke Sandgren)(cn=3D{T.61}\caAke Sandgren))
> > =
>
> > but if this does not match then another filter is tried, an
> > approximate match, and I get the following strange filter
> > =
>
> > | ((sn~=3D{T.61}3AKE SANDGREN)(cn~=3D{T.61}3AKE SANDGREN))
> > =
>
> > Which, not surpricingly, doesn't match anything.
>
>
> I tried to duplicate this at our site and observed the following:
>
> 1. The problem doesn't seem to be in the LDAP client code -- it looks
> like the correct filters are being constructed there.
>
> 2. When our ldapd submits the search to a QUIPU DSA, the approximate
> search filter logged by QUIPU looks stange, as you observed. I
> tried this on an ICR1 DSA.
>
> 3. When our ldapd submits the search to the GDA DSA we run here for
> our primary service, the correct filters are logged in all cases.
>
> I didn't check to see if the searches work correctly or not, but it seems
=
> to
> me that QUIPU is doing something odd here, probably when it does some
> normalizing of the search filter to do the approximate searching. I
didn'=
> t
> go as far as to look at the DSA code though.
>
> -Mark
>