Home/ Questions/Q 926095
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T19:37:42+00:00

We’re having a problem getting Word documents to download in IE7/IE8 using window.open calls.

  • 0

We’re having a problem getting Word documents to download in IE7/IE8 using window.open calls. This problem is currently only happening in our production environment with SSL enabled – our test environment is working correctly but does NOT have SSL enabled. Both environments are running IIS6 and use integrated authentication.

The javascript is pretty simple:

    function OpenNewWindow(sURL, sName, sHeight, sWidth)
{
    var sFeatures = "top=40,left=190,toolbar=no,location=no,directories=no,menubar=no,scrollbars=yes,resizable=yes,status=no";
    sFeatures = "width=" + sWidth + ",height=" + sHeight + "," + sFeatures;

    var newWindow = window.open(sURL, sName, sFeatures);
    newWindow.focus();
}

The above function is being passed relative paths, and the page itself (an ASP.NET page) is pre-formatted HTML. The code-behind for the page is setting the content type to “application/msword” and allows ASP.NET to write the contents of the page to the output stream.

When the above function is called, a new window is created and then immediately closes without any errors or prompts. As far as I can tell (using Fiddler) caching is enabled and HTTP compression is NOT enabled. The actual document content is returned, but there seems to be some kind of disconnect between IE and Word.

An oddity I’ve noticed are that in test there is an negotiate challenge put out and responded to with a Kerberos ticket while in production no challenge/response occurs (although one does occur on the opening page and the response is NTLM). Addtionally, a direct link to the page (Word document) in question DOES work correctly in both environments. Finally, unchecking the “Confirm open after download” option for the .DOC file type allows the document to be successfully opened (but is NOT a solution we are willing to pursue for 2000+ employees).

I know this is limited information and I may need to add more details, but I’ve spent the better part of a day searching/testing and do not feel any closer to resolving this problem. Any help would be greatly appreciated!

Headers for both environments:

TEST request (works correctly, no SSL)
GET /webapps/gfcse/CSEPrint.aspx?mode=ReadOnly&sSurveyId=3060 HTTP/1.1
Accept: /
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)
Host: pc55516svma
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=elto5pakakvepbju42w24eef
Authorization: Negotiate [snip]

TEST response
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 26458
Content-Type: application/msword; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6421
WWW-Authenticate: Negotiate [snip]
X-AspNet-Version: 2.0.50727
Date: Thu, 08 Jul 2010 15:14:26 GMT

[document content]

PRODUCTION request (does NOT work, SSL enabled)
GET /gfcse/CSEPrint.aspx?mode=ReadOnly&sSurveyId=3582 HTTP/1.1
Accept: /
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)
Host: intranet.gfnet.com
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=h2xw0ebweb4e2455iab1tvbf

PRODUCTION response
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 26438
Content-Type: application/msword; charset=utf-8
Server: Microsoft-IIS/6.0
MicrosoftSharePointTeamServices: 12.0.0.6219
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Date: Thu, 08 Jul 2010 15:07:41 GMT

[document content]

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The problem, as it turns out, has nothing to do with the headers but rather what we were attempting to do via javascript – automatically downloading files.

    Because our test and production environments are in different security zones there were different settings affecting the file downloads (specifically the “automatic prompting for file downloads”). Since we were trying to download files via javascript in a zone that had the information bar enabled, the browser was doing what it is supposed to. There are a few different ways to address this (i.e. group policy, downloa

    A similar problem is solved in this thread: IE7 issue – cannot download streamed file when Automatic prompting for file downloads is disabled

    • 0