On Fri, 16 Feb 2007, Achint Mehta wrote:

> 3. Then the function Curl_output_digest (http_digesti.c) is called which
> checks whether we have nonce value for this request (if(!d->nonce)). Since
> we don't have a nonce value we return from this function without encoding a
> new Authorization header. However, the previous Authorization header is
> still present in conn->allocptr.userpwd field. And may be this field is used
> eventually in the GET request.

But sending the previous auth header can't be considered to be terribly bad,
can it? I mean, libcurl can't know for what paths on the server when it needs
a new auth negotiation to take place.

The only thing is that libcurl should then of course react properly on the 401
response as it would if no auth header at all had been sent.

> 4. I changed the code in function CreateConnection where the new user-name
> and password are being copied to the connection structure, to free the
> allocptr.userpwd field and set it to NULL.

Since this is HTTP, it is perfectly fine for an application to change user and
password between requests and they can still re-use the same connection fine,
so I don't think this sounds like the correct procedure. Re-using a HTTP
connection does not imply the same user + password.

> 3. I found a similar query http://curl.haxx.se/mail/lib-2003-11/0148.html.
> However, this issue was resolved without a explicit code-change. May be this
> was the cause for this.

Sorry, but I don't see how that issue is similar to this. And even if it was,
I'm not sure looking back on that old solutions or is any help for our current
situation.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html