Hello! I am Venkat Kudallur, development lead for Networking in Internet Explorer. We have made several improvements in Internet Explorer in Networking, and in this post, I would like to introduce you to some of the improvements in content caching and decompression in IE, two features that play a key role in speeding up the delivery of pages from a remote web server. If you’re a webmaster, developer using the IE Networking API, or just curious about IE Networking, I think you’ll find these details interesting.
A quick introduction to the key IE modules used in Networking is called for:
The key takeaway is that the bulk of http implementation, including caching, lies within WinInet, while UrlMon provides a COM wrapper around it and allows extension and filtering.
Prior to IE7, decompression happened in the UrlMon layer as a pluggable layer. The IE gzip and decompression was exposed through COM, and generically plugged in by the UrlMon implementation to work on the compressed data stream exposed by the WinInet Win32 API. The model was nice because any new decompression formats could be nicely plugged in as a COM implementation and registered with UrlMon to use on the compressed data stream. In practice, there were conditions under which this logical separation of decompression from the download complicated the model. For IE7, we have moved the decompression to logically sit above the download implementation within WinInet. This approach gives us several benefits:
I expect that these changes fix a set of issues commonly seen in IE and IE-hosted applications when compression is used, particularly when there is dependence on the cache file used to store the content on the browsing machine. Developers consuming UrlMon and WinInet API need not be concerned about any changes in API behavior resulting from this change in IE7 – the UrlMon API continues to decompress compressed data transparently, and the WinInet API, by default, returns compressed data as in prior versions.
WinInet.dll is responsible for a cache, which is loaded and synchronized across all the processes and services using it. In addition to serving as a cache for various types of content downloaded by WinInet, it’s also exercised through the use of the WinInet caching API which provides a URL-based index for storage and retrieval. Its popularity, however, brings with it the downside of any instability (e.g. corruption of the index from a sudden reboot in the middle of a write-through operation) impacting all the processes that use it. We have significantly rewritten the WinInet cache index manager IE7 to ensure that it can gracefully recover from corruption or failure to grow the memory mapping of the index file. In addition we have improved the caching heuristics, extensively scrubbed API for parameter validation, and now handle Internationalized Resource Identifiers (IRI) more consistently in the API. I expect huge stability and functionality gains from the caching changes made in this release.
To read more on the impact of caching and compression on HTTP performance, check out this article by Eric Lawrence, IE Networking Program Manager. I welcome your feedback and suggestions for IE Networking features or for topics you would like us to blog about.