Please read my blog's comment policy here.
Earlier today, I was asked to troubleshoot a secure site where file downloads were always failing. Having seen this problem many times often over the years, I immediately suspected that the web developer wasn’t aware that
if a user tries to download* a file over a HTTPS connection, any response headers that prevent caching will cause the file download process to fail.
* Note that this applies to “downloaded” files that open in programs other than IE. It does not apply to resources that render inside IE’s HTML rendering engine, like images/script/css/etc.
When Internet Explorer encounters a HTTPS download that will not be cached, the download is aborted with the following dialog box:
The Fiddler web debugger allows you to easily check to see whether a download contains headers that prevent caching.
Cache-preventing headers include:
Without changing the site’s code, you can easily confirm that the problem is caused by cache-prevention headers using Fiddler’s Filters tab:
Fiddler allowed me to determine that today’s instance was caused by cache-preventing headers. After the web developer updates these headers to allow local caching (e.g. Cache-Control: private, max-age=15) the file download process will work correctly.
-Eric
PS: In the unlikely event that the user has checked the Do not save encrypted pages to disk option inside Tools / Internet Options > Advanced, this error dialog may be shown for any file downloads from secure sites, regardless of caching headers. I recommend that folks avoid enabling this option, and use the Delete Browser History on Exit feature instead.
Update Oct. 2010: I've conducted some further investigation of this issue, and found that (surprisingly) you CAN specify Cache-Control: no-store, no-cache and the download will work, but if you specify these directives in the opposite order, it will fail. Additionally, if you include a Pragma: no-cache header, the secure response will not be cached regardless of other headers. As a comment notes below, the behavior is slightly different for direct navigation (e.g. URL in the address bar) vs. a hyperlink navigation (e.g. user clicks on a link).
Update Feb. 2011: I've modified the file download logic for IE9. IE9 should be able to successfully download a file regardless of HTTPS or Cache-Control headers unless you have the "Do not save encrypted pages to disk" option set.
IE changes the extension on almost all file downloads, forcing me to save as change the extension and then open. This happens with Groupon when I try to print a voucher for instance. Furthermore, when I download an executbale (.exe) it changes the extension. It is like there is a remapping of the period to an underscore for anything but .htm or .html.
[EricLaw]: This is a configuration problem somewhere on your machine. Please contact me using the link at the top-right to let us investigate.
Very cool - thanks for the help.
Was able to get it working via:
string attachment = "attachment; filename=" + rptName + ".xls" + "";
HttpContext.Current.Response.Clear();
HttpContext.Current.Response.ClearHeaders();
HttpContext.Current.Response.AddHeader("content-disposition", attachment);
HttpContext.Current.Response.AddHeader("Cache-Control", "private, max-age=1");
HttpContext.Current.Response.ContentType = "application/vnd.ms-excel";
HttpContext.Current.Response.Charset = "";
HttpContext.Current.Response.Buffer = true;
HttpContext.Current.Response.Cache.SetExpires(DateTime.Now.AddMinutes(1));
We had the exact same issue. In our case the problem was caused by McAfee HBSS/IDS
This is for the one other person in the world that will run in to this:
I have some old code that uses the Tabular Data Control (msdn.microsoft.com/.../ms531356%28v=vs.85%29.aspx). I ran in to this issue when I had a script that generates a CSV file. In the headers I had a Pragma: no-cache. This file was then being consumed by the TDC over https. In IE8, it would not display the content over https, but would over http. In IE9 it worked fine. I spent some time looking for the bug and found the problem with the header by trial and error. Then after finding it, I did a search for Pragma: no cache over https and found this site. Thanks for helping me to see what was causing the error.
@Jon: Yup, that's exactly the same culprit. There's some more discussion of this in this post: blogs.msdn.com/.../downloads-and-flash-fail-when-do-not-save-encrypted-pages-to-disk-is-set.aspx
When I download any file over HTTPS, the resulting file is corrupt. Using the same code over HTTP is fine.
I've tried various combinations of:
Response.AddHeader "Cache-Control", "private, max-age=15"
Response.AddHeader "Pragma", "no-cache"
Response.AddHeader "cache-control", "no-store, must-revalidate, private"
Response.AddHeader "Cache-Control", "no-store, no-cache"
at different code locations. Do these lines need added at a certain location, e.g. before adding other headers?
@Tito: Can you explain what specifically is "corrupt" in the cases you're referring to? What browser are you using, and what are the final set of headers?
i've seen the same issue when trying to "view source" of an xml file. If my web-server tells the browser *"do not cache"*, then Internet Explorer does as it's told, and saves **no** copy of the file.
The logic of the (original) situation seems "reasoanble" when you explain it that way. How can an external program (like Excel or Notepad) open a file off the hard-drive, when Internet Explorer has been told not to save a copy.
One reason for specifying "no-cache" is so that the browser will always get a *"fresh"* copy of the server. Another reason can be that the information is somewhat sensitive, and we'd rather you didn't keep a copy on the hard-drive if at all possible.
Having much the same problem: Using IE9-x64 on Windows 7 Ultimate. NOT using "do not save encrypted pages". HAVE set BypassSSLNoCacheCheck=1. STILL cannot save downloads from banks to disk using IE9. Can do this with Mozilla. What's going on?
We've experienced this problem with IE8 and Pentaho. Unable to download reports generated by the system using IE8 but could using IE9 and other browsers when using SSL. In the end we fronted it with an Apache server doing SSL termination, and configured Apache with "mod_headers" to remove the offending headers.
This didn't work on it's own, we also had to disable the "Do not store encrypted pages to disk" setting.