This blog is closed as of 2/2015. @EricLaw left Microsoft in 2012, but was named an IE MVP in '13 & an IE userAgent ( in '14.

Internet Explorer Cannot Download https://something

Internet Explorer Cannot Download https://something

  • Comments 45

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:

Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found.

The Fiddler web debugger allows you to easily check to see whether a download contains headers that prevent caching.

Cache-preventing headers include:

  • A Cache-Control header with the tokens no-cache, no-store
  • A Vary header that specifies almost anything 
  • A Pragma header that specifies exactly no-cache

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 Filter UI: Remove Cache-Control Header

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.


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.AddHeader("content-disposition", attachment);

           HttpContext.Current.Response.AddHeader("Cache-Control", "private, max-age=1");

           HttpContext.Current.Response.ContentType = "application/";

           HttpContext.Current.Response.Charset = "";

           HttpContext.Current.Response.Buffer = true;


  • 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 ( 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:

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

  • I've changed Cache-Control: and Pragma: and downloads in IE8 through SSL now work but only if you type the URL into the address bar. If you click on the link in an email it still gives the error. Fiddler shows that in both cases the headers are identical. What gives?

    EricLaw: And what, exactly, are the headers in question?

  • Thank you for a very interesting and hopefully useful blog.

    I have the opposite problem. Getting IE (10) to stop caching my page. I have an  .aspx that draws (bars using System.Drawing and the bitmap i then saved as a physical but temporary .png  and rendered whit an htmlImage scr=...png. There is a dropdown (time) causing postbacks but the images are never regenerated due to caching. Chrome and FireFox works fine but IE just don't quit

  • @Tomas: What are the exact headers on the HTTP response? One *very rare* issue I've seen with ASP.NET partial-page updates is that images with unchanged URLs can be reused out of Trident's per-page image cache, so request doesn't even go to the network stack where cache headers would be evaluated. But this is very rarely the issue, the most common problem is failure to set proper headers on the response.

  • @EricLaw: Thanks for the response. In both cases the headers are identical and as follows:

    HTTP/1.1 200 OK
    Date: Thu, 24 Oct 2013 02:46:03 GMT
    Server: Apache/2.2.16 (Debian)
    Vary: Host
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: no-store, no-cache
    Pragma: private
    Content-Disposition: attachment; filename="19062351.doc"
    Content-Length: 4905
    Connection: close
    Content-Type: text/rtf

    Again, pasting or typing the URL into the address bar works but clicking on it in an email does not. Interestingly, sometimes the first time you paste it into the address bar you get the same error but clicking go or hitting enter a second time works. This is IE8 on WinXP. Prior to setting Cache-Control: no-store, no-cache and Pragma: private the links were never working in IE8, now they are working just not when clicked on in an email. I've also tried the other variations for Cache-Control: listed on this page and the behavior stays the same.

    Thanks Eric I really appreciate your feedback, I can't find any solution for this online, everything just mentions the Cache-Control: and Pragma: headers that I think I already have set correctly.

    [EricLaw] Remove the meaningless Pragma header. Remove the Vary header. Change the Cache-Control header to be Cache-Control: private, max-age=10.


  • Thank you so much Eric, for the response. The Pragma: and Vary: headers were being set if I didn't specify them so I looked into explicitly removing them. You were right, that and changing Cache-Control to 'private, max-age=10' did the trick. Its working now with these headers:

    HTTP/1.1 200 OK

    Date: Sat, 26 Oct 2013 20:02:32 GMT

    Server: Apache/2.2.16 (Debian)

    Expires: Thu, 19 Nov 1981 08:52:00 GMT

    Cache-Control: private, max-age=10

    Content-Disposition: attachment; filename="19062351.doc"

    Content-Length: 4905

    Connection: close

    Content-Type: text/rtf

    For those who are interested, I'm using PHP and this is the code I used to get it working:

    // check for IE only headers

    if (isset($_SERVER['HTTP_USER_AGENT']) && (strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE') !== false)) {

    header('Cache-Control:  private, max-age=10');




    Thanks again Eric, I really appreciate your help on this.

Page 3 of 3 (45 items) 123