Word document downloaded with window.open doesn't open (IE7/IE8)

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 en开发者_运维百科abled - 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]

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

I think you'll find this isn't really an issue to do with javascript, more an IE and HTTP headers issue. We had a similar issue trying to open csv files different combinations of headers will work correctly others wont.I cant remeber which ones are needed, these are what we ended up having to set

note this is in php but you should be able to translate to .net

setHeader("Expires", gmdate("D, d M Y H:i:s") . " GMT")
setHeader("Last-Modified",  gmdate("D, d M Y H:i:s") . " GMT")
setHeader("Cache-Control", "", true)
setHeader('Content-Disposition', 'attachment; filename=' . $filenameToReturn)
setHeader('Content-type', 'application/octet-stream')
setHeader("Content-length", sprintf('%d', filesize($this->view->filename)));

Now that I think about the issues is with the Cache-Control header, and it must be empty

You can use System.Web.HttpResponse to force the files to be downloaded from the users' browser.

Protected Sub btnDownloadMe_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btnDownloadMe.Click



    Dim filename As String = "demo.docx"

    'For old version of MS Word use application/msword

    Response.ContentType = "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
    Response.AddHeader("Content-Disposition", String.Format("attachment;filename={0}", filename))
    Response.[End]()


End Sub