IE8 won't download a file with a custom mime/type with UAC enabled

Question

I have a .net service running on the local machine (Windows 7 x64, IE8, .net 3.5, C#) that returns a file to the browser in response to a user action. Using firefox or chrom

Answer 1

For me the solution to this problem was changing

Response.ContentType = "application/vnd.ms-excel";

to

Response.ContentType = "text/csv";

Answer 2

From MSDN

If Internet Explorer knows the Content-Type specified and there is no Content-Disposition data, Internet Explorer performs a "MIME sniff," scanning the first 200 bytes of the file to determine if the file structure matches any known MIME types. For more information on MIME sniffing, see MIME Type Detection in Internet Explorer. If the MIME sniff detects a MIME type known to Internet Explorer, and the file has not been loaded by a mimefilter already, Internet Explorer sets that file extension before placing the file in the local browser cache.

Lastly, if there is no Content-Type or Content-Disposition data, and the MIME sniff does not recognize a known MIME type, the file extension is set to the same extension as the URL used to download the file.

If the file is marked as "content-disposition=attachment" in the HTTP header, Internet Explorer treats the file name from the URL as final and does not rename it before placing it in the cache.

content-disposition=attachment is that the solution ?!?

/Erling Damsgaard DNS-IT ApS

Answer 3

We had this same problem embedded in our ClickOnce deployment of www.Qiqqa.com. I suspect it has to do with the "MIME Type sniffing" that IE does when it gets an application/octet-stream - I guess to protect the user from malicious stuff.

Anyway, to solve the problem, we changed the mime type of our .deploy files to be text/plain - obviously not ideal, but at the same time, I don't know a scenario where we might have a .deploy file on our server that a user would browse to outside ClickOnce.

Answer 4

I was able to solve this issue today. It turns out that the codebehind was setting the CacheControl property of the response to HttpCacheability.NoCache. Removing that line of code solved the issue. The other half of the fix was correctly registering the mime type and file extension with a ProgId.

I stripped down the response to just content-disposition: attachment; filename=xxx and a binary write of the string data. IE correctly displayed the Open or Save dialog box, even though the mime sniff reported the file as text/html (which really should have been text/plain).

I added back the content type header and retested, then the nosniff option and retested and finally the cache control. In between each test, I rebooted the VM to ensure it was a pristine testing environment (ie, nothing cached or preloaded). Only the cache control line affected the behavior in a negative fashion.

Answer 5

Need to make sure "no-store" appears in your header before "no-cache". See this post: http://blogs.msdn.com/b/ieinternals/archive/2009/10/03/internet-explorer-cannot-download-over-https-when-no-cache.aspx