On Mon, 1 Sep 2003, Joerg Mueller-Tolk wrote:

> the handling of failed authentification with NTLM is not yet satisfying.

Can you tell me an example on how to get into trouble with the current
approach?

> 1. On failing we currently fall back to round trip state zero on and on.
> Where is the best location to break the NTLM authentification cycle?

The current code already attempts to detect this situation by detecting when
the NTLM state is moved "backwards" (http_ntlm.c:142).

> This happens i.e. if you set CURLOPT_PROXYUSERPWD to "" which is then
> defaulted in CreateConnection() to CURL_DEFAULT_USER and
> CURL_DEFAULT_PASSWORD (currently "anonymous:curl_by_daniel_at_haxx.se").

Aren't you mixing matters now? They're set in the user+password fields if
CURLOPT_USERPWD (note that this is not the CURLOPT_PROXYUSERPWD) option wasn't
used.

> Should we rather try checking the scheme in the url before setting a
> default?

We could. I don't think we ever use the default user+password when we talk
HTTP, so copying that data is a pure waste in that case.

> 2. If you set CURLOPT_PROXYUSERPWD to NULL we will segfault in
> Curl_output_ntlm() with ntlm->state NTLMSTATE_TYPE2 or later in mkhash(). (I
> would be happier to add a NULL check before strlen() and toupper().) The
> quickest implementation would be to return !=0 from Curl_output_ntlm() but
> is this OK

We could argue if setting CURLOPT_PROXYUSERPWD to NULL should still be trying
to use any authentication method at all, so we could just return an error if
this is the case. Can you figure out any sensible use case when NULL is
expected to be set?

(I'm currently working on re-arranging some source-code to better support the
auth stuff for the proxy CONNECT loop.)

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf