William A. Rowe, Jr. wrote:
That's correct. Windows utf-8 code page 65001 or so is only a psuedo
page
in all older and (afaik) newer flavors of windows). So it's returning
this
character in the local code page, can't represent it, and falls back
on '?'.
Yup, and that's what our assumption
Stusynski, Dan wrote:
The corrupt DN is coming back with a hex value of 3F (question mark)
when the sequence should be hex values e68891 (or 346\210\221) in
decimal).
That's correct. Windows utf-8 code page 65001 or so is only a psuedo page
in all older and (afaik) newer flavors of windows).
Subject: Re: Apache - MS LDAPSDK with multi-byte DN
On Thu, Jul 17, 2008 at 11:00 AM, Andy Wang <[EMAIL PROTECTED]> wrote:
> Basically the dn returned in the following two lines is already
> mangled with the ? character:
> entry = ldap_first_entry(ldc->ldap, res);
>
On Thu, Jul 17, 2008 at 11:00 AM, Andy Wang <[EMAIL PROTECTED]> wrote:
> Basically the dn returned in the following two lines is already mangled with
> the ? character:
> entry = ldap_first_entry(ldc->ldap, res);
> dn = ldap_get_dn(ldc->ldap, entry);
>
> Thanks,
> Andy
What's the byte sequ
Sequence of events are as follows:
ldap_search_ext_s to an ldap URL and search base that does not contain
UTF-8 characters.
manager bindDn and bindPw do not contain UTF-8 charaters (all are
US-ASCII) only. The attribute being searched for (uid) does not contain
UTF-8 characters as well.
For
On Wed, Jul 16, 2008 at 4:55 PM, Andy Wang <[EMAIL PROTECTED]> wrote:
> the case where we're seeing this none of the arguments contain anything
> other than US ASCII characters. If you're ldap_search_ext_sW call contains
> only US-ASCII but the returned DN contains UTF-8 shouldn't this still work
William A. Rowe, Jr. wrote:
For what it's worth I also did try using the ldap_search_ext_sW call
directy inside the uldap_cache_checkuserid function but that resulted
in a filter error.
Yup :)
So if you were to tweak things to decode utf-8 into unicode and then
invoke
the W flavor, it sho
Stusynski, Dan wrote:
Apache is compiled to support unicode by default from what I can tell.
Not exactly ;-) Apache/WinNT is built around UTF-8. In APR, we twist the
char args ourselves and then call the wchar FooW API function where we know
APR_HAS_UNICODE and the version tests clean as NT
Eric Covener wrote:
> 2008/7/16 Stusynski, Dan <[EMAIL PROTECTED]>:
>
>> Hello devs,
>>
>> It would appear that the MS LDAP SDK has an issue when Apache is compiled
>> against it.
>>
>> Our Apache 2.2.9 compiled with VC6 on Windows against the MS LDAP SDK seems
>> to have an issue when searchi
2008/7/16 Stusynski, Dan <[EMAIL PROTECTED]>:
> Hello devs,
>
> It would appear that the MS LDAP SDK has an issue when Apache is compiled
> against it.
>
> Our Apache 2.2.9 compiled with VC6 on Windows against the MS LDAP SDK seems
> to have an issue when searching for a DN that contains multibyt
Hello devs,
It would appear that the MS LDAP SDK has an issue when Apache is compiled
against it.
Our Apache 2.2.9 compiled with VC6 on Windows against the MS LDAP SDK seems to
have an issue when searching for a DN that contains multibyte characters (non
ascii), in this case a Chinese characte
11 matches
Mail list logo
