cURL / Mailing Lists / curl-library / Single Mail


Re: SSPI proxy authentication fails for large post strings

From: Dan Fandrich <>
Date: Tue, 10 Mar 2015 21:23:33 +0100

On Tue, Mar 10, 2015 at 05:28:59PM +0000, Abram Pousada wrote:
> I have run into an issue where proxy authentication appears to fail under the following conditions:
> * libcurl (7.41.0) was built (VC10-12) with USE_WINDOWS_SSPI defined.
> * Using any (CURLAUTH_ANY) or negotiate (CURLAUTH_NEGOTIATE) for proxy authentication.
> * The HTTP post includes a post string greater than TINY_INITIAL_POST_SIZE (defined in http.h as 1024) characters in length.
> * Specified domain credentials are provided explicitly, from a computer which is not attached to the domain.
> * Operating systems which this issue was verified so far include Windows 7 SP1, Windows 8, and Windows 8.1 (I can test in other versions if needed).
> The proxy server is a Forefront TMG 2010 server (I recognize mainstream support for this ends soon), which requires integrated authentication for Active Directory users. Under the above conditions, it responds with an HTTP 407, even though it works just fine with a post less than or equal to 1024 characters in length. Here are the command arguments (this helped isolate the issue outside of our affected application) used to debug the library via the VS2013 solution:
> -U "[domain]\[username]:[password]" --proxy-negotiate --proxy [host:port] --data "@$(UserProfile)\Desktop\request.txt" [postUrl]
> After debugging a bit, I did find that I can prevent libcurl from going down the affected code path by explicitly setting an empty Expect header. (The command argument equivalent is --header "Expect:".) Other proxy authentication methods seem to function without this workaround. For example, explicitly using NTLM proxy authentication works just fine when this logic goes down the Expect: 100-continue path. Is setting the empty Expect header like this the best/safest way of implementing an immediate workaround?

The 100-continue feature of HTTP/1.1 isn't often used and lots of software gets
it wrong. It could be that this server is one of those. If you post the debug
trace of a failing session, we should be able to tell what is going wrong.

>>> Dan
List admin:
Received on 2015-03-10