FIX: Double GET and Cookies Lost with Word or ExcelID: Q185978
|
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 this to be a bug in the Microsoft products 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.
<%@ 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 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.
<%@ 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
%>
Additional query words:
Keywords : kbActiveDocs kbASP kbIE400bug kbIE401bug kbIE302bug kbIE500fix
Version : WINDOWS:3.02,4.0,4.01,4.01 SP1
Platform : WINDOWS
Issue type : kbbug
Last Reviewed: April 8, 1999