Article ID: 185978 - View products that this article applies to.
This article was previously published under Q185978
This article has been archived. It is offered "as is" and will no longer be updated.
When Internet Explorer connects to a Web server resource that dynamically generates Word, Excel, or other Active Documents, Internet Explorer may send two GET requests for the resource. The second GET usually does not have session state information, temporary cookies, or authentication information that may have already been specified for the client.
This bug can affect any local server (EXE) Active Document application hosted inside the Internet Explorer frame window. It occurs most frequently with ISAPI, ASP, or CGI applications that adjust the HTTP "Content Type" header to identify the installed application.
Internet Explorer can sometimes lose information pertinent to a particular download for an Active Document server (Word, Excel.) When this occurs, Internet Explorer is able to activate the Active Document server but when the server attempts to bind to and read the data for the document, Internet Explorer re-downloads the document from the context of the server.
When the server is an out-of-process local server, the second download is treated as a new session with the Web server. This is by-design and comparable to connecting to the server from two open browser instances.
To avoid this problem, Web server applications should not rely on consistent session cookie or authentication information for documents served in this manner.
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article. This bug was corrected in Microsoft Internet Explorer 5.
This problem is specific to Active Document servers that use IPersistMoniker to read their persistent data; Word 97 and Excel 97 are the most common examples. When the Active Document server obtains a moniker through IPersistMoniker::Load and then calls BindToStorage on that moniker to get the data, URLMON should continue the download in the context of the original Internet Explorer process that instantiated the Active Document server. Because of the bug described by this article, URLMON instead starts a fresh new download in the context of the Active Document server process.
Potential workarounds from the Active Document server side involve removing IPersistMoniker support or reading directly from the cache file name for the moniker's associated URL.
Steps to Reproduce BehaviorThe following two Active Server Pages (ASP) pages will reproduce this bug. The first page sets a temporary cookie that should be valid for the entire session:
As expected, the Web page will display "Cookie Did Not Exist" when first visited. Subsequent visits and refreshes of the page will display "Cookie Exists" because the session cookie has now been set in Internet Explorer for that session.
When clicking on the link in this page, the following MakeWordDoc.asp page will be evaluated and downloaded. On systems with Microsoft Word installed, Word will be loaded and hosted inside the Internet Explorer frame window with the text contents of the evaluated ASP code.
MakeWordDoc.asp demonstrates the problem because the session cookie will never be valid. The Word document will almost always contain "Error - Cookie Did Not Exist" on Internet Explorer 4.0x. The results are erratic on Internet Explorer 3.0x.
Article ID: 185978 - Last Review: February 23, 2014 - Revision: 3.1