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.

  • Can you clarify "downloaded files" a bit more? Does only apply to files with "Content-Disposition" response headers? Or is it simply any response with a Content-Type which IE does not handle natively?

  • @Billy: "this applies to “downloaded” files that open in programs other than IE" means "any response with a Content-Type which IE does not handle natively."

  • This behavior seems kind of silly.  Is there a particular threat we're protecting against?  Is copy/paste blocked too?  Blocking these downloads seems like it will just discourage people from using HTTPS.

  • If a secure (SSL) web app builds content to the filesystem and points the browser at those files for download, it also must modify the IIS settings for that file, or it will fail for IE‽

    > "this applies to “downloaded” files that open in programs other than IE" means "any response with a Content-Type which IE does not handle natively."

    Content-Type based on the header, or content type detected by sampling the data?

  • > "This behavior seems kind of silly."

    :-) I've used a variety of words to describe it, most of which are a bit harsher than "silly."

    I should have noted that this behavior has existed since (at least) IE6.  It's something that major customers (especially banks) had asked for, without really understanding what it would mean for the user-experience.

    Obviously (considering the confusing UI) this wasn't a scenario where a major investment was made.

    > "it also must modify the IIS settings for that file, or it will fail for IE‽"

    No, unless IIS configuration had already been modified to send a "no-cache" header. By default, IIS wouldn't send this header, and hence this problem would not be encountered.

    > "Content-Type based on the header, or content type detected by sampling the data?"

    The distinction is irrelevant in this case.

  • > It's something that major customers (especially banks) had asked for,[…]

    Wait, so this is not a bug but a feature? I still don't get what the security gain could be. AFAIK, https traffic shouldn't be cached anyway. And on top of that, if that's a 'security feature' why this misleading error message?!

    Apropos banks requesting security features, what about "X-Force-TLS"?

  • << AFAIK, https traffic shouldn't be cached anyway.>>

    That's an incorrect assumption.

    << what about "X-Force-TLS"? >>

    A number of folks are interested in the Strict Transport Security spec.

  • « That's an incorrect assumption. »

    Maybe, for when some evil villain is able to read your cache (the one on the disk) all is lost anyway.

    The equivalent of "Do not save encrypted pages to disk" is in Firefox the the about:config entry "browser.cache.disk_cache_ssl" which is set to "false" by default. So – unlike IE – Firefox isn't caching content coming through HTTPS par default. I guess Mozilla had their reasons for deciding on this default behaviour, particularly as it means a sacrifice of performance on HTTPS pages.

    BTW/OT: I wish I will also find my life's calling where I would be so dedicated that I would reply to blog post comments on Sundays. :)

  • "Firefox isn't caching content coming through HTTPS par default"

    Last time I looked, in current Firefox versions, if a Cache-Control: public header is present, Firefox will cache the HTTPS-delivered content.

  • The setting makes complete sense on shared machines. If someone decides to access their inbox on a public computer with auto-login, other people shouldn't be able to dig up what they were looking at over SSL. Perhaps I'm too paranoid but I always make sure that setting is checked. Thanks for the heads-up about Firefox, Eric.

  • @WillH: Generally speaking, it's never safe to browse private sites on an untrusted PC, because the PC may contain keyloggers or other spy software.

    Rather than tweaking the setting (which doesn't really work like you hope it does), you should use the "Delete Browser History" command or IE8's InPrivate Browsing feature.

  • @WillH: The problem with disabling caching for all HTTPS traffic is that it makes HTTPS slower and more expensive for web site operators.  That means fewer of them will deploy HTTPS and everyone's security suffers to mitigate this marginal threat.

    If you don't want something cached, send a cache header with that instruction!

  • I tried the idea of changing the values for Cache-Control, Expire...etc! But didn't work, but when I tried changing the value of header 'Pragma' from 'Pragma: no-cache' to 'Pragma: ', it works!

    Works in FF, IE, Safari, and Google Chrome.

    Thanks for the idea... God speed everyone!

  • @Ryan: You shouldn't be sending a Pragma header at all. But yes, if you send a Pragma that forbids caching, you'll see behavior as described in this post.

  • I'm running into this on my site but we're using straight HTTP, not HTTPS.  We have caching disabled (Cache-control: no-cache) for our download area due to a customer request.  Strangely, the problem only happens if I type in the URL to the file directly:"> .  If I go to our download page ( ) and click the link, it works just fine.

    Any ideas?

Page 1 of 3 (45 items) 123