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
curl-http.patch
Description: curl-http.patch
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
