For posting to both URLs, our code has one method which sets up all the curl_easy_setopt() options and then calls curl_easy_perform(), reusing the curl handle between calls. The function does exactly the same for both URLs (there is nothing like _if(url==foo) { a; } else { b; }_ ). The function sets CURLOPT_PROXY, CURLOPT_PROXYUSERPWD and CURLOPT_PROXYAUTH in both cases and always with the same values.

The problem seems to be that the authentication is sent only for the first time and then, even though the connection was closed and we received the 407 reply, curl doesn't try to authenticate again. I have tried modifying that method to close the curl handle and open a new one on each request. The problem disappeared immediately and it works fine, authenticating when required. Unfortunately, this also means we need to open a new connection and authenticate for each request even if the connection to the proxy was not closed.

---
** [bugs:#1433] POST with Proxy NTLM auth: curl suddenly stops sending Proxy-Authorization**
**Status:** open
**Labels:** ntlm proxy authentication 
**Created:** Thu Oct 09, 2014 04:18 PM UTC by Víctor Fernández Martínez
**Last Updated:** Thu Oct 23, 2014 08:38 PM UTC
**Owner:** Daniel Stenberg
Our application uses the easy interface to do a simple POST request to a HTTP server. The same curl handle is reused between POST requests. We use a HTTP proxy with NTLM authentication (usually, squid). The application is single-threaded. Our code was working fine with libcurl 7.18.2. However, after upgrading to 7.38.0, the problems started, even though we didn't modify the application.

The problem is that libcurl sometimes suddenly stops sending authentication headers to the proxy. When this happens, the proxy replies with "407 Proxy Authentication Required". libcurl then retries the POST again but without any authentication headers. Therefore, the proxy answers with 407 again. This leads to a loop that causes hundreds of POST requests per second to be send and lasts until the query timeout is reached. The problem is not always reproduceable. One way to reproduce it is by using a firewall and forcing the connection to be closed from the firewall or by using some command. This allows the problem to be reproduced around 3/4 of the time. However, the problem happens sometimes spontaneously even though we didn't forcefully close the connection.

Please see the attached network capture. You can open it under Wireshark. There are several requests at the beggining, which worked fine. We forced the TCP connection to be closed from the firewall and when we performed the next request, the problem happened (starting on packet #69).

We are setting the following parameters with curl_easy_setopt() in the same order they appear here:

* CURLOPT_PROXY
* CURLOPT_PROXYUSERPWD: in the form "domain\\username:password" (ASCII characters only, URL-encoded using curl_easy_escape())
* CURLOPT_PROXYAUTH: CURLAUTH_ANY
* CURLOPT_TIMEOUT: 20 seconds
* CURLOPT_NOSIGNAL: 1
* CURLOPT_HTTPHEADER (added cookies)
* CURLOPT_POSTFIELDS
* CURLOPT_URL
* CURLOPT_WRITEFUNCTION
* CURLOPT_WRITEDATA

and then we call curl_easy_perform(). Interrupting curl with gdb almost always shows the following backtrace (which of course looks normal):

	(gdb) bt
	#0  0xf7764425 in __kernel_vsyscall ()
	#1  0x410fe73b in poll () from /lib/libc.so.6
	#2  0xf772607f in Curl_poll () from /usr/lib/libcurl.so.4
	#3  0xf77221a8 in curl_multi_wait () from /usr/lib/libcurl.so.4
	#4  0xf7718954 in curl_easy_perform () from /usr/lib/libcurl.so.4
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.