Hi,

we tested a little bit more:

For authentication conn->allocptr.proxyuserpwd is set in the various backends.
curl_ntlm and curl_ntlm_wb might free it (in NTLMSTATE_TYPE3, if it reaches this stage), all the others don't.

So with negotiate proxy authentication it looks like this: first it issues some request getting 407, then it finally succeeds.
All further requests still have the header set (but shouldn't); and while the proxy ignores the header for GET, it will reject POST requests with 407 and close the connection.

With NTLM and curl_easy_reset it sometimes works, and sometimes doesn't (perhaps related to DNS? It looks like it doesn't work with a DNS name which resolves to multiple IPs, but works with a fixed IP).

We couldn't reproduce the behavior that Negotiate and curl_easy_reset are working, so reusing the handle probably triggers NTLMSTATE_TYPE3, and new connections don't.


Summary: the "Proxy-Authorization" header is (almost) never reset, and the proxy doesn't like the header (for POST) after the authentication.

Now in http.c the "Authorization" header (userpwd) is freed:

  /*
   * Free userpwd now --- cannot reuse this for Negotiate and possibly NTLM
   * with basic and digest, it will be freed anyway by the next request
   */

  Curl_safefree (conn->allocptr.userpwd);
  conn->allocptr.userpwd = NULL;

Freeing proxyuserpwd too after these lines fixed the problem for us (we're still testing what other side effects this might have); see attached patch.

It would be nice to get some feedback whether this is the right approach :)

Regards,
Stefan

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html