From: Seshubabu Pasam <pasam_at_seshubabu.com>
Date: Wed, 02 Mar 2005 18:03:26 -0800

I am not sure if libCurl is capable of handling non-ASCII chars. Daniel? But since you already sniffed the packets etc, why don't you decode them? The type-3 message should have the user name in it. Take a look at http://davenport.sourceforge.net/ntlm.html to find out the offset of the username in the type-3 message.

-Seshu

hep monk wrote:

When I ask libCurl to fetch an NTML-protected page on IIS 6.0 and supply regular ASCII credentials:

 

username: domain\fred

password: secret

 

everything works fine, the NTLM handshake succeeds and I get the page.

 

However, when I try to do the same using credentials that have non-ASCII characters in the username, the NTLM handshake fails and I don't get the page. I used the CP1252 character set to encode my non-ASCII European characters, just like IE 6.0 does:

 

username: domain\fenêtre (the sole non-ASCII character is 'e' with a circumflex on it, which in CP1252 is the byte 0xEA)

password: secret

 

From packet sniffs, we see that all three types of NTLM messages, type 1, 2, and 3, are exchanged. However, the final response from the server is a 401 instead of a 200.

 

If I input the exact same credentials into IE 6.0 or Firefox 1.0, this works fine: the browser is able to fetch the NTLM-protected page.

 

Note: Basic Authentication with non-ASCII credentials works fine.

 

Questions:

1) Is libCurl capable of handling non-ASCII NTLM credentials?

2) If it is, what might I be doing wrong?

3) If it is not, is there a plan to implement this soon?

 

Thanks.

---

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web

Received on 2005-03-03