The WinINet API was added to Windows in Windows NT4 and Windows 95. This API set is located in Wininet.dll and is used by WinINET-aware applications such as Internet Explorer, Media Player, and Instant Messenger. The WinINET API itself enables applications to interact with the Gopher, FTP and HTTP protocols. WinINet abstracts these protocols to provide application developers with an interface that resembles standard file IO. Something important to note here is that WinINet is not intended to be used by a server application or Windows service. This is due to the user interaction that is often required by applications that leverage WinINet - such as User Dialogs etc. When writing serviced-based applications, winHTTP.dll should be used instead. This DLL is based on the WinINET API set, but has been modified so that user response (dialogs, etc) has been removed.
So how does WinINet work? WinINet leverages the underlying sockets interface and emulator to access the network as shown in this diagram. It builds its services on top of this infrastructure. WinINet also interfaces with other OS components to provide services such as security and manipulation of the TCP/IP Stack configuration. In addition, upper layer protocol implementations such as UPnP also leverage WinINet. WinINET talks directly to Winsock when making it's request. In its most basic form Internet Explorer is a Winsock application.
When dealing with WinINet issues, there are two important DLL's to consider, wininet.dll and urlmon.dll. Let's take a look at each of these. The diagram below shows the relationship of these components:
WININET.DLL : This DLL exposes the Windows Internet API. It provides the interface between applications using WinINet and Windows Sockets. Applications that use this API check to see whether an Internet connection exists, and establish a connection if necessary. To accomplish this, WinINet leverages the Remote Access API (RASAPI). Once a connection is verified, the application can open a handle to the remote resource, request a connection for a specific protocol and open sessions on that handle for HTTP, FTP or Gopher communications. WinINet provides capabilities such as:
- Caching, History, Cookie Management
- Authentication - Basic, NTLM, Kerberos
- Connections - Both secure (schannel) and non-secure
- Dial-up, Direct, Proxy
- Protocol and HTTP header management
It is during this process that any proxy settings are verified and handled, the username is retrieved (if required) and a connection is made with the server through sockets for any FTP requests. A connection to the server is not created for HTTP requests until the request is actually sent. If necessary, WinINet communicates with Crypto components such as SCHANNEL.DLL. WinINet.Dll provides support for many things, including cookies, history, header interpretation and processing (for example web page redirection and keep-alives), authentication and encryption. WinINet.Dll leverages another DLL, URLMON.DLL for various activities dealing with URL's.
URLMON.DLL : This DLL is the URL Moniker support library for WinINet. A moniker is just a nickname that is used to make an object more familiar and recognizable. The following functions are handled by URLMON.DLL:
- URL Parsing – breaking down URLs into the protocol used (HTTP, HTTPS, FTP, File, Gopher), address, and target.
- GZIP compression/decompression – provides support for GZIP HTTP compression to deflate and inflate data. IE6 and IE7 handle this slightly differently. In IE7 this functionality is handled by WinINet.
- Security and Zone Management – Identifies security zones, zone crossings, permissions, etc.
- Asynchronous Pluggable Protocol Filter/Handler – correlates appropriate the protocol to the registered handler (HTTP, HTTPS, MAILTO, FILE, etc.).
- Code Download Management, Install On Demand, and Just-In-Time.
- Forms requests from the URL – creates the outbound data package and hands it off to WININET for transfer.
- MIME (Multipurpose Internet Mail Extension) type management – examines the MIME type for data returned in an HTTP response and correlates that type with a specific handler. For example, URLMON would open a Microsoft Word document (MIME type .doc) with Microsoft Word. If the MIME type is not clear from the response, URLMON is capable of examining the binary data to determine the appropriate MIME type. MIME is described more thoroughly in RFC1521.
And that brings us to the end of this post. In upcoming posts,we will discuss WinHTTP and also look at some troubleshooting scenarios which will better explain when and how to gather the proper data to assist in root cause analysis of Internet Explorer issues. I'd like to thank Brent Goodpaster, one of our Escalation Engineers, for his review and feedback on this post. Until next time ...
Additional Resources:
Microsoft