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 chrome, the file is downloaded properly and our application is launched via a custom mime type and all is well.

However, with IE8, I receive a dialog "unable to download file from . Unable to open this internet site. The requested site is either unavailable or cannot be found. Try again later".

Using fiddler, I verified that IE does receive the payload from the service.

If I turn off UAC, IE does download the file and launch the associated application.

Turning off UAC is not a viable solution, as our customers will have it enabled.

How can I get IE8 to launch the associated application with UAC enabled?

EDIT:

After reregistering the mime type with a programmatic id as described here, I can get IE to open show the "Open or Save" dialog for the SECOND time the link is requested from the address bar. Why doesn't it work the first time?

Answer 1

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 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

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