ie9 hangs when streaming file to browser

Question

I use the following to stream a file (usually Excel or PDF) to the browser. It operates by setting the location of a hidden iFrame to a download handler which contains the code.

t works fine in Firefox etc and in some instances of IE9 but not other instances of IE9.

Where it doesn't work the Information bar appears but there is no option to Open, only Save or Cancel.

The Information bar then hangs and can't be closed or cancelled.

Also the URL is changed so that the dot before the file prefix (eg .xls or .pdf) is changed to an underscore.

A typical correct one is

/export_templates/rawdata/downloadfile7.asp?fID=@_pdf@{875CFEE5-23D4-42CB-8885-7A9D493DC616}.pdf&fname=Quick%5Fpoll.pdf

Has anyone seen this or found a fix. There's no add-ons enabled, no av stopping it. We've compared settings in IE, av and firewall on machines where it does and does not work and they are identical.

Set adoStream = CreateObject("ADODB.Stream")
adoStream.Open()
adoStream.Type = 1
adoStream.LoadFromFile(f.Path)
dataSize = f.size
Response.Buffer = true
Response.CharSet = "UTF-8"
Response.clear
Response.ContentType = "application/x-unknown" ' arbitrary
Response.AddHeader "Content-Length", dataSize
Response.AddHeader "Content-Disposition","attachment;filename=" & thisfname

Response.flush
do while not adoStream.eos
    Response.BinaryWrite adoStream.Read(1024 * 8)
    Response.flush
loop
Response.End()
adoStream.close
set adoStream=nothing

Answer 1

I see two potential issues with the code above and two potential "extenuating circumstances":

1.) Not quoting the filename. I've seen issues when using:

Content-Disposition: attachment;filename=File Name.pdf vs. Content-Disposition: attachment;filename="File Name.pdf"

Note the double-quotes around the filename. This matters when the name contains spaces or other unsafe characters.

2.) Wrong Content-Type. As mentioned in comments above this is an important cue to the system how the file should be treated. For PDF's you really should be using application/pdf

3.) Different transfer encodings. It's possible this issue only affects gzipped (deflate) content. It wouldn't be the first time IE has failed to handle compressed streams properly.

4.) If you're seeing different results between copies of the same browser you should attempt to establish whether they also have the same minor version as well as os, plugins, toolbars and PDF readers. Any of these things could be a factor.