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 dynamicallygenerates Word, Excel, or other Active Documents, Internet Explorer maysend two GET requests for the resource. The second GET usually does nothave session state information, temporary cookies, or authenticationinformation that may have already been specified for the client.
This bug can affect any local server (EXE) Active Document applicationhosted inside the Internet Explorer frame window. It occurs most frequentlywith 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 particulardownload for an Active Document server (Word, Excel.) When this occurs,Internet Explorer is able to activate the Active Document server but whenthe server attempts to bind to and read the data for the document, InternetExplorer re-downloads the document from the context of the server.
When the server is an out-of-process local server, the second download istreated as a new session with the Web server. This is by-design andcomparable to connecting to the server from two open browser instances.
To avoid this problem, Web server applications should not rely onconsistent session cookie or authentication information for documentsserved 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 useIPersistMoniker to read their persistent data; Word 97 and Excel 97 are themost common examples. When the Active Document server obtains a monikerthrough IPersistMoniker::Load and then calls BindToStorage on that monikerto get the data, URLMON should continue the download in the context of theoriginal Internet Explorer process that instantiated the Active Documentserver. Because of the bug described by this article, URLMON instead startsa fresh new download in the context of the Active Document server process.
Potential workarounds from the Active Document server side involve removingIPersistMoniker support or reading directly from the cache file name forthe moniker's associated URL.
Steps to Reproduce Behavior
The following two Active Server Pages (ASP) pages will reproduce this bug.The first page sets a temporary cookie that should be valid for the entiresession:
<%@ LANGUAGE="VBSCRIPT" %><% ' Check for cookie and add if it does not exist myCookie = Request.Cookies("mycookie")("test1") If mycookie = "" Then Response.Cookies("mycookie")("test1")="OK! The Cookie Exists" End If%><HTML><HEAD><TITLE>A Page That Sets a Temporary Session Cookie</TITLE></HEAD><BODY><% If myCookie = "" Then%> Cookie Did Not Exist<P><% Else%> Cookie Exists<P><% End If%><A HREF="MakeWordDoc.asp">Click Here</A></BODY></HTML>
As expected, the Web page will display "Cookie Did Not Exist" when firstvisited. Subsequent visits and refreshes of the page will display "CookieExists" because the session cookie has now been set in Internet Explorerfor that session.
When clicking on the link in this page, the following MakeWordDoc.asp pagewill be evaluated and downloaded. On systems with Microsoft Word installed,Word will be loaded and hosted inside the Internet Explorer frame windowwith the text contents of the evaluated ASP code.
MakeWordDoc.asp demonstrates the problem because the session cookie willnever be valid. The Word document will almost always contain "Error -Cookie Did Not Exist" on Internet Explorer 4.0x. The results are erratic onInternet Explorer 3.0x.
<%@ LANGUAGE="VBSCRIPT" %><% Response.ContentType = "application/msword" %><% mycookie = Request.Cookies("mycookie")("test1") %><% ' Check For Cookie If mycookie = "" Then%> Error - Cookie Did Not Exist<% Else%> OK! Cookie Exists.<% End If%>