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?

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

Solution 2

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

Solution 3

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

Solution 4

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.

View more solutions

Comments

[Rich]

Is the custom MIME type even necessary? Wouldn't application/octet-stream suffice?

[Jeff Paquette]

Good question. As far as I know, it's how IE determines what program to use to launch an application. This is a closed-loop here, it's our datafile, and our viewer. How else would we do it?

[JamesUsedHarden]

If you use a generic mime type like application/octet-stream and a custom file extension that you've registered with your viewer (within you're viewer's installer), will IE (and everything else) display it then?

[Jeff Paquette]

If i switch to octet-stream, IE presents the open or save dialog. If I pick "open" it opens it in the browser instead of in the associated application. If I drop the security slider for the internet zone to the lowest setting (using the custom mime type), the associated app is launched, even with protected mode on.

[Pekka]

Does it have to be a MIME type? Doesn't association by file extension work? What kind of file is that?

[Jeff Paquette]

It's a text file containing command line parameters to be passed to the handler program.

[Jeff Paquette]

Removing the mime type and relying on file type association still does not work.

[Jeff Paquette]

No, that's not it, though it seems like it should be.

[somshivam]

this at first sight appears to be a hit and trial; but it worked for me. Also see [Same solution proposed on MSDN blog] blogs.msdn.com/b/ieinternals/archive/2009/10/03/…