On Thu, 1 Oct 2009, Joshua Kwan wrote:
So I've received another bug related to NTLM on my radar, it doesn't work
when non-ASCII characters have to be passed in as part of the username or
password. It turns out that this is because cURL does not set the UNICODE
negotiation flag.
I poked around the source tree and noticed that cURL does not even try to
link against iconv unless you manually configure it like that (even though
99% of the time it's going to be in C library anyway.) Why is this?
That's because there's nothing in a "normal" libcurl builds that needs it.
Also, since we use char* and not wchar_t for everything, would it be safe to
say that the default codeset for the host should be UTF-8 these days?
(ISO-8859-1 is *so* 20th century..)
I don't know. The NTLM docs by Eric Glass says "An OEM string is a string in
which each character is represented as an 8-bit value from the local machine's
native character set (DOS codepage).". Which makes it feel even older ;-)
I'm just trying to gauge what the official opinion of cURL developers is on
the iconv front before I get to coding.
Would it be a working approach to instead offer an API for providing the name
and password as UTF-8 or UTF-16 encoded and thus avoid having to recode them
within libcurl?
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
