1

I'm trying to POST to a secure site using WinHttp, and running into a problem where the User-Agent header isn't being sent along with the CONNECT.

I am using a lightly-modified code sample from MSDN:

  HINTERNET hHttpSession = NULL;
  HINTERNET hConnect     = NULL;
  HINTERNET hRequest     = NULL;

  WINHTTP_AUTOPROXY_OPTIONS  AutoProxyOptions;
  WINHTTP_PROXY_INFO         ProxyInfo;
  DWORD                      cbProxyInfoSize = sizeof(ProxyInfo);

  ZeroMemory( &AutoProxyOptions, sizeof(AutoProxyOptions) );
  ZeroMemory( &ProxyInfo, sizeof(ProxyInfo) );

  hHttpSession = WinHttpOpen(L"WinHTTP AutoProxy Sample/1.0",
    WINHTTP_ACCESS_TYPE_NO_PROXY,
    WINHTTP_NO_PROXY_NAME,
    WINHTTP_NO_PROXY_BYPASS,
    0);

  if(!hHttpSession)
    goto Exit;

  hConnect = WinHttpConnect( hHttpSession,
    L"server.com",
    INTERNET_DEFAULT_HTTPS_PORT,
    0 );

  if( !hConnect )
    goto Exit;

  hRequest = WinHttpOpenRequest(hConnect, L"POST", L"/resource", NULL, WINHTTP_NO_REFERER, WINHTTP_DEFAULT_ACCEPT_TYPES, WINHTTP_FLAG_SECURE );

  if( !hRequest )
    goto Exit;

  WINHTTP_PROXY_INFO proxyInfo;
  proxyInfo.dwAccessType = WINHTTP_ACCESS_TYPE_NAMED_PROXY;
  proxyInfo.lpszProxy = L"192.168.1.2:3199";
  proxyInfo.lpszProxyBypass = L"";

  WinHttpSetOption(hHttpSession,
    WINHTTP_OPTION_PROXY,
    &proxyInfo,
    sizeof(proxyInfo));

  WinHttpSetCredentials(hRequest, WINHTTP_AUTH_TARGET_PROXY, WINHTTP_AUTH_SCHEME_BASIC, L"proxyuser", L"proxypass", NULL);

  if( !WinHttpSendRequest(hRequest, WINHTTP_NO_ADDITIONAL_HEADERS, 0, "content", 7, 7, 0))
  {
    goto Exit;
  }

  if(!WinHttpReceiveResponse(hRequest, NULL))
    goto Exit;

    /* handle result */

Exit:

  if( ProxyInfo.lpszProxy != NULL )
    GlobalFree(ProxyInfo.lpszProxy);

  if( ProxyInfo.lpszProxyBypass != NULL )
    GlobalFree( ProxyInfo.lpszProxyBypass );

  if( hRequest != NULL )
    WinHttpCloseHandle( hRequest );

  if( hConnect != NULL )
    WinHttpCloseHandle( hConnect );

  if( hHttpSession != NULL )
    WinHttpCloseHandle( hHttpSession );

What this does is connect to my server through an authenticated proxy at 192.168.1.2:3199, and make a POST. This works, but when I examine the proxy logs the User-Agent string ("WinHTTP AutoProxy Sample/1.0") is not being sent as part of the CONNECT. It is however sent as part of the POST.

Could someone please tell me how I can change this code to have the User-Agent header sent during both the CONNECT and POST?

Edited to add: we are observing this problem only on Windows 7. If we run the same code on a Windows Vista box, we can see the User-Agent header being sent on CONNECT.

Duncan Bayne
  • 3,870
  • 4
  • 39
  • 64

1 Answers1

2

Duncan-- Per the WinHTTP team, this was a behavioral change introduced in Windows 7. At present, there is no workaround for this issue in WinHTTP.

EricLaw
  • 56,563
  • 7
  • 151
  • 196
  • Thanks greatly. Thought I was going crazy for a while :-) – Duncan Bayne Mar 10 '10 at 23:30
  • Eric, since I posted this question we have had to re-engineer our software to use HTTP rather than HTTPS, because we are being rejected by filtering proxies in corporate networks that filter on the basis of User-Agent. If you're in touch with them, please let the WinHTTP team know that this has been a right pain in the a** for us, and the sooner they get this regression (sorry, behavioural change) fixed the better for all Windows developers. – Duncan Bayne Mar 15 '10 at 13:33
  • Duncan: You should contact Microsoft support (http://support.microsoft.com) and get a case filed for this; that's the path to getting a fix released by Microsoft. As this was a change in our behavior, the support charges should be waived. – EricLaw Mar 15 '10 at 17:23
  • Eric: I tried calling Microsoft in Australia (13-16-30) and was told by a rude, overbearing CSR that it would cost hundreds of dollars to file a report, that there was no way the charge would be waived, and that his supervisor would say the same thing if I spoke to him. All in all, that's not how I'd expect to be treated when spending my own time to help by reporting a defect for which I've already found a work-around. – Duncan Bayne Mar 30 '10 at 01:53
  • Eric: the workaround was, sadly, to provide the option of disabling HTTPS in our comms layer and rely on our existing PKI tamper-proofing functionality. That enables customers who wish to operate over HTTPS from behind proxies that filter on user agents. – Duncan Bayne Mar 30 '10 at 01:58
  • 2
    FYI, to anyone following this, within 24 hours the Microsoft folk in the US have got in touch, apologised for the inconvenience, & have raised an issue free of charge. I'm a happy camper again :-) – Duncan Bayne Mar 31 '10 at 23:54
  • @duncan-bayne so have they MS released any fix to winhttprequest? Or they just filed the case, that's all? – Anatoly Alekseev Oct 01 '19 at 05:52