On Fri, 19 Dec 2003, Daniel Stenberg wrote:

> It should pick NTLM in the call to Curl_http_auth_act(), used
> from line lib/transfer.c:457 in my version.
>
> Can you add some printf() code around that to see why it
> doesn't pick ntlm for the situations when the test case
> fails? And if it _does_ pick NTLM even when it fails, then we
> have a problem with the following request...

I think it does pick NTLM in both the working and failed case. The failed
case looks like this:

Curl_read worked OK (nread = 253)
Curl_http_auth_act: data->state.authavail is 0x00000009
Curl_http_auth_act: assigning CURLAUTH_NTLM (0x08) to data->state.authwant
Curl_read worked OK (nread = -1)
curl: (52) Empty reply from server

The working case looks like this:

Curl_read worked OK (nread = 253)
Curl_http_auth_act: data->state.authavail is 0x00000009
Curl_http_auth_act: assigning CURLAUTH_NTLM (0x08) to data->state.authwant
Curl_read worked OK (nread = 421)
Curl_http_auth_act: data->state.authavail is 0x00000000
Curl_read worked OK (nread = 160)
Curl_http_auth_act: data->state.authavail is 0x00000000
Finally, this is the real page!
Curl_read worked OK (nread = 0)

I tried looking at this in a protocol analyzer, but since I'm using
127.0.0.1 I guess nothing ever makes it to the ethernet driver. Any good
tools out there (that run on Windows or cygwin) that'll capture everything
on the loopback IP interface?

Is it possible that there's an extra swsclose in the test data?

-DB

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Received on 2003-12-19