Under the Hood: WinHTTP

A couple of weeks ago we took a look at WinINet.  Today, our focus shifts to WinHTTP.  The WinHTTP API is designed to provide client side HTTP services to server applications.  If you recall from our post, WinINet was designed as an HTTP API client platform that allowed the use of interactive message dialogs such as entering user credentials.  By contrast, WinHTTP’s API set is geared towards a non-interactive environment allowing for use in service-based applications where no user interaction is required or needed.  WinHTTP can be leveraged using either the Win32 API set or a COM interface.

WinHTTP version 5.1 is an OS-level component of Windows 2000 SP3 and later (except Datacenter Server), Windows XP SP1 and later and Windows Server 2003 SP1 and later. 

Some of the features of WinHTTP version 5.1 include:

  • IPv6 support
  • Autoproxy capabilities
  • HTTP/1.0 protocol including support for persistent connections and session cookies
  • HTTP/1.1 chunked transfer support
  • Secure Sockets Layer (SSL) support including client certificates.  Supported SSL protocols include SSL 2.0, SSL 3.0 and Transport Layer Security (TLS) 1.0
  • Support for server and proxy authentication, including integrated support for Microsoft Passport 1.4 and the Negotiate / Kerberos package
  • Automatic handling of redirects unless suppressed

As with WinINet, WinHTTP leverages the underlying Sockets Interface and Emulator to access the network, as shown below.  WinHTTP is similar to WinINet – except that WinHTTP only provides the API’s to support the HTTP protocol.  Protocols such as Gopher and FTP are handled by WinINet.

The WinHTTP API is implemented in WinHTTP.DLL and exposes both COM methods and a Win32 API.  In addition, there is an AutoProxy API exposed that enables applications to discover the proxy configuration.  An application uses WinHTTP in similar fashion to how a client application would use WinINet.  The first step in the process is for the application to get a session handle to WinHTTP.  Once WinHTTP has been opened, the application uses this handle to configure information about the server with which it wishes to communicate.  This does not actually cause WinHTTP.DLL to make a connection using Sockets – the HTTP request must first be created.  Only then is the connection to the server through sockets instigated and the HTTP request sent.

The AutoProxy API’s are provided to make it easier for applications to configure and discover proxy settings.  The Web Proxy Auto-Discovery (WPAD) protocol is implemented by WinHTTP version 5.1 for this purpose. WPAD uses DHCP and / or DNS to locate a Proxy Auto-Configuration (PAC) file on the client’s local network.  The PAC file is downloaded and may be cached on the client computer.  A PAC file is a script that generates a list of one or more proxy servers given a target host name and URL.  The script is executed on each HTTP request to compute list of one or more proxy servers that can be used to transmit the request.  It is important to remember that WinHTTP supports only ECMAScript-based PAC files.

And that brings us to the end of our look at WinHTTP.  We will be looking at troubleshooting scenarios in a future post.  I’d like to express my thanks once again to Brent Goodpaster, one of our Escalation Engineers, for his contributions to this post.  Until next time …

Additional Resources:

CC Hameed