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