- **status**: open --> pending-needsinfo
- **Comment**:

OK, then at least we know that you can do a work-around to get it going. But it doesn't really explain why that code ruins anything since it does create a new connection so it shouldn't inherit NTLM state from the previous... Or can you explain why this changes things for you?

---
** [bugs:#1433] POST with Proxy NTLM auth: curl suddenly stops sending Proxy-Authorization**
**Status:** pending-needsinfo
**Labels:** ntlm proxy authentication 
**Created:** Thu Oct 09, 2014 04:18 PM UTC by Víctor Fernández Martínez
**Last Updated:** Fri Oct 31, 2014 01:17 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.