BUG: HTTP Compression wth Frameset Causes "Page Cannot Be Displayed" Error

If you load a frameset with at least two frames, and both frames point to the same server-side object (such as an Active Server Pages [ASP] page that is named Test1.asp) but the frames use different query string parameters, and you turn on HTTP compression on the Internet Information Services (IIS) server for dynamic pages, you may receive the following error message in one of the frames:

Internet Explorer caches uncompressed pages in such a way that, occasionally, one of the uncompressed pages is deleted before it has been loaded.

To resolve this problem, use one of the following methods:

• Create several copies of your server-side object with different names, such as Test1a.asp and Test1b.asp. Make sure that the frames for each frameset reference different copies of this object.
• If you are using Internet Server Application Programming Interface (ISAPI) DLLs instead of ASP pages or Common Gateway Interface (CGI) scripts, create a set of small ISAPI filters by using Microsoft Foundation Classes (MFC), and use the OnUrlMap event handler to change the pszPhysicalPath variable in the HTTP_FILTER_URL_MAP structure. The benefit of this is that you can keep only a single copy of your application logic on the server, which can reduce potential confusion when you update your DLL. For more information about OnUrlMap, visit the following Microsoft Developer Network (MSDN) Web site:
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_mfc_CHttpFilter.3a3a.OnUrlMap.asp

Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.

For example, suppose that Frame 1 in the scenario points to test1.asp?Param=Test1, and Frame 2 points to test1.asp?Param=Test2. To uncompress the pages, Internet Explorer strips the query string and the .asp suffix and replaces the .asp suffix with an .htm suffix. It then creates a cache file with this new name and puts all uncompressed contents in the cache file. Shortly thereafter, MSHTML (the new HTML rendering engine in Internet Explorer) reads in the contents of this file and loads it by using a stream.

When the cache file is created, all previous cached versions of that page are deleted. This means that, if the response for Frame 2 comes from the server before Frame 1 has read its cache file, Frame 2 deletes the cache file for Frame 1 before it writes out its own cache file (note that the cache file for Frame 1 now has a name, Test1.htm, that is exactly the same). When Frame 1 tries to use CreateFile() on its cache file with the GENERIC_READ access attribute, it receives ERROR_FILE_NOT_FOUND.

Although this problem reproduces frequently, it does not reproduce every time that you access a page. Sometimes both frames appear appropriately; sometimes one frame does not appear, and sometimes the other frame does not appear. This depends on a number of conditions, including current processor workload and network latency. The slower your computer or the larger your latency, the less likely you are to see this problem.

For more information about developing Web-based solutions for Microsoft Internet Explorer, visit the following Microsoft Web sites: