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.

  • Like Don, I get this error using HTTP and not HTTPS and only if the user follows a link within an email or types the URL in IE directly. Strangely it only happens to users within our corporate network. External visitors can access the files fine either via links or by entering the address directly into the browser. Enabling caching is not an option as we then get an alternative error "myfile.xls is locked for editing by 'me' Open 'Read-Only', or click 'Notify' to open read-only..."

    Is there any resolution to this?

  • I developed a activex. and signed it, and make cab file,  and  also signed it. It worked fine when download from http://something in WinXP and windows7 (IE7)client.

    but when download from https://something in WinXP and windows7  (IE7)client. it doesn't work. (can't download anything)

    in Win XP, I checked  [Do not save encrypted pages to disk] option, so download activex OK from https://something.

    but windows7 still can't work.

    Is there any resolution to this?

    Any advice please.

  • @DonPratt, @SimonJ, @Schin: Please send me (via email) the exact headers on the response. You can capture these via the Fiddler Web Debugger (; for HTTPS sites, you'll need to enable HTTPS decryption in the Fiddler options.

  • I solved my problem now.

    The cause is we used tomcat as our  web server. the tomcat add Cache-Control header  when the server site is https.

    thank you very  much.

  • Hi Eric; right now I'm having this issue at the QA server, but there's a little problem, I wasn't  using any kind of cache control.

    In my localhost it works just fine, but at QA displays that error, so i added the control cache that you used as example and it keeps going fine in my local

    and keeps sending the error message at the QA server, could you please give me some advice?

    This is the code (well, the part that is making me get hairless); I forgot, is Classic ASP and the QA server is not HTTPS

    Response.Buffer = TRUE


    Response.ContentType = "application/"

    Response.AddHeader "Cache-Control: private, max-age=15","attachment; filename=Reporte_Detallado.xls"

    Thanks in advance

  • @Jose: And if that's literally your code, the line AddHeader is wrong. You're trying to add two headers with just one line, and that won't work. I think you mean to say:

    Response.AddHeader "Cache-Control", "private, max-age=15"

    Response.AddHeader "Content-Disposition", "attachment; filename=Reporte_Detallado.xls"

  • I am facing the same problem. Mine is JSP with tomcat with https... It works fine in fire fox it breaks in IE.. any work around for this...

  • @Drew: The article itself talks about workarounds, which leads me to believe that you're having some other problem entirely. If you email me a network trace (, I'm happy to have a look at it.

  • Great post, though I'm still having problems. I've tried amending my .net code, as suggested above, by adding:

        Response.AddHeader "Cache-Control", "private, max-age=15"

    but that hasn't solved it. After that change, I've used Fiddler to delete the Cache-Control header as directed, but I was still getting an Expires: -1 so also had to delete the pragma header (by entering "pragma; cache-control" in the Fiddler 'Delete response header' textbox). This then allowed the download of an Excel file from a page served over https

    My question is, what else do I need to do in my code ? Perhaps this :


    Thanks in advance.


  • @Iain: Pragma: no-cache will prevent caching. If your page is sending that, you need to reconfigure it not to. If you don't know how to suppress that header, you'll need to ask in an ASP.NET forum.

  • Thanks Eric. I've got it working now. In case it helps others, here's my code:



           HttpContext.Current.Response.AddHeader("content-disposition", String.Format("attachment; filename={0}", fileName))

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

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


    I imagine it's the ClearHeaders() statement that has removed the pragma header.

  • Thanks a lot Eric for the article. It saved me from a tough debugging session.

    Your tip on the header "Cache-Control: no-store, no-cache" was a great hint. I got my file working over SSL now. Thank you once again, have a good day!

  • Thanks, you just saved my sanity. Beer is on me!

  • Thanks. This worked for JSP , Tomcat, HTTPS. Set the Header follows on HttpServletResponse:
    response.setHeader(CACHE_CONTROL,  "private, max-age=15");

  • Coming very late to this conversation, but to those who say that no HTTPS content should ever be written to disk, what if you have a paystub site that gives you your paystub as a PDF?  How do you get that PDF to open in your PDF reader if you don't have it on disk?  What if you want to print something?  The print spooler operates on files.

    As Eric says, if someone can access your Temporary Internet Files folder, they have lots of other ways to control your user account; e.g., capture the HTML or other data after it has been downloaded by your browser and decrypted.  HTTPS provides point to point encryption, but at the endpoints it's in the clear.

Page 2 of 3 (45 items) 123