After upgrading from 5.1 to 5.2, IE can no longer download/open files on the site. Mozilla, Safari, Opera all work. When I right-click on the file and go to save-as I get "The file could not be written to the cache". This has cropped up only since the upgrade to 5.2 from 5.1. The site is only accessible via SSL and the file system is "private".

running on Gentoo Linux, Apache-2.2.4, PHP-5.2.2, Drupal-5.2

#43 ie_cannot_dl_over_ssl-163445-43.d6.patch959 bytespescetti
#42 ie_cannot_dl_over_ssl-163445-42.d6.patch908 bytesgreg.1.anderson
#35 ie-private-downloads-over-ssl-163445-35.patch953 bytesmlsamuelson
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch ie-private-downloads-over-ssl-163445-35.patch.
[ View ]
#24 drupal5-uploadmodule-msie-fix-if-https.patch1.35 KBwebengr
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal5-uploadmodule-msie-fix-if-https.patch.
[ View ]
#20 drupal5-uploadmodule-patch-msie-ssl.patch1.17 KBwebengr
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal5-uploadmodule-patch-msie-ssl.patch.
[ View ]
#3 ie-settings-screendump.gif21.57 KBjoep.hendrix


I've dropped back to 5.1 and the issue is gone.

This problem is still present in 5.3

new21.57 KB

I can confirm that this problem is still in D5.3.
With the a certain advanced setting this can be avoided (see attachment).
This setting is not standard so please consider this as a bug.


I am also seeing this issue for a website that is setup to be private andl https, and not viewable by annoymous,
and was upgraded from 4.X to version 5.7

So this is still an issue ass of later April 2008

Version:5.2» 5.7

I am also seeing this issue for a website that is setup to be private andl https, and not viewable by annoymous,
and was upgraded from 4.X to version 5.7

So this is still an issue ass of later April 2008

This is a bug that has not been resolved for version 5.7 so I put it up as a bug here for that version:

I've marked the other issue as duplicate of this one.

To clarify: this is working fine in 5.1 but broken in 5.2 and later, yes?

Is it an issue in HEAD? What about on a fresh install?

Version:5.15» 5.7

I setup three FRESH INSTALL websites using the dev branch for versions 5, 6, 7


short answer YES BUG EXISTS for head of 5 and 6, could not test 7 because of upload module error in the dev.
NOTE I tested for 5.x dev that the bug is only for PRIVATE, not PUBLIC download method.

THE ssl cert is self signed, so you will have to accept that to see sites...

I just tested 2008-Jun-07
and for https with PRIVATE upload, the MS IE bug is still rampant.

HERE IS THE SITE AND AN ACCOUNT TO TEST. I made notes on the page and set user to view and download only.
(please others, don't change the test account user settings... so we can get this fixed) (redirects to https)

user: test
password: abc123


I am going back and doing 6.x-dev and 7.x-dev now, ... DONE


FOR 6.x DEV 2008-Jun-09 (redirects to https)

user: test
password: abc123



FOR 7.x DEV 2008-Jun-11 (redirects to https)

user: test
password: abc123

notice: Undefined variable: file in ***/drupal-7.x-dev/modules/upload/upload.module on line 151.

BTW, problem still exists even on dev.

since the other theads for other versions are not suppose to be used,
could you change the title of this thread to say since 5.2, both 5.x and 6.x problem ?

FYI, I had this problem as well and WebFM module worked for me as a workaround. Saving files still doesn't work, but I am dealing with mostly pdf's that I want people to just open anyway.

I am still trying to fix the problem, and I think it is related to an overall problem I am having where file downloads don't get completely downloaded. For me I think I have tracked it to a problem with max_execution_time in php.ini. I don't know if this is how it is supposed to work, but, it seems that a script is executing the entire time the file is downloaded (this is a problem for my > 100MB files). That mean't that files were downloaded some and then timed out leaving you with a file that IE thinks is corrupt. I increased max_execution_time and my early tests indicate that this fixes the problem.

So, maybe my issue is unrelated> I am running IIS 6 with SSL and WebFM module (workaround for private file system) on Drupal 5.7.

I appreciate the input, but I don't think it is related to the size of the file, and it did work before on earlier versions of 5.x,
some change to the code for 6.x and later 5.x caused https private download to have errors... unless you disable the ssl setting...

so don't think it is an apache thing.

I can confirm this, using drupal 6.6 private download method and https.

Version:5.7» 5.15


I've encountered this problem now, too, after having set up SSL for our Drupal 5.15 site.
Files are accessible through private download method (which works fine without SSL).
When I try to open files in IE 6 and IE 7 the error message is:

Internet Explorer cannot download filename from sitename.
Internet Explorer was unable to open this Internet site. The requested site is either unavailable or cannot be found. Pleast try again later.

The same documents can be opened without a problem in Safari and Firefox.

Could you please let me know if there will any attempts to fix this bug?
SSL is important for my client as is the use of IE.

Drupal 5.15
Apache 2.2.3
PHP 5.1.6
MySQL 5.0.45

Thanks and cheers,

I found the following solution on the web which solved the issue for my installation without any further issues (so far):

I added a Cache Control entry in the file_download section that controls all my file downloads ($type and $size obviously being set dynamically in my script):

return array('Content-Type: '.$type, 'Content-Length: '.$size, 'Content-Transfer-Encoding: binary', 'Cache-Control: max-age=60, must-revalidate');

Alternatively (but not realistic in the environment that I work in), activate the setting Don't save encrypted pages to disk in Internet Explorer, menu ToolsOptionsAdvanced.

Version:5.7» 5.15

Apologies, but we may need some clarification on your fix,

Are you referring to ./includes/

and function file_download()

And if so, is the return you are suggesting simply placed before the closing curly brace for the function?

BTW -- this problem still exists for IE8 I have been told.

webengr, the function drumming_cat is refering to is in modules>upload>upload.module. there is a return array already there that is returning the headers. you just need to add to what is already there. I am away from my drupal install so hopefully that was specific enough. if not let me know if you still need help because i know how frustrating this problem can be, and i can give you more specifics.

This doesn't have anything to do with the file system directly, but I recently encountered the "Internet Explorer cannot download..." problem while attempting to implement the public/private download solution described in this article. The solution provided by drumming_cat worked perfectly.

I prefer dogs over cats, but props to this kitty.

I have hesitated to elevate this bug, but it would be nice to fix this on 5, 6 and beta 7.

every time we do an update, this work around will get removed because it is a core module.?

can we make a patch and have the core developers look it over and get it into the core for 5,6, and 7,
since this module is core?

and get the patch to work against which function... returning array... that is messing up the https?

and looking in the upload module, as expected, several functions...

I agree this is a problem, but use hook_file_download() to add the needed attributes.

new1.17 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal5-uploadmodule-patch-msie-ssl.patch.
[ View ]

OKAY per promise, a patch is attached, the patch is for drupal 5, and includes comments for the developers to review.

Thank you for the above drupal users finding that it was a MSIE cache control problem for ssl connections.

I found the Microsoft web page explaining that MSIE has to prevent caching for SSL download:

And here is the w3 page explaining Cache-Control:

So yes on the upload module, ./modules/upload/upload.module
for drupal 5 around line 261, function upload_file_download($file)
the return array needed additional information to suggest to microsoft browsers not to store cache.

The Microsoft website suggested for SSL: 'Cache-Control: no-store',
Above what was recommended was 'Cache-Control: max-age=60, must-revalidate'

I tried 'Cache-Control: no-store', that worked
I tried 'Cache-Control:max-age=60', that worked
I tried 'Cache-Control:must-revalidate', that worked
I tried 'Cache-Control:max-age=60, must-revalidate', and that worked also for drupal 5 with MSIE https.

Since the latter was suggested above, and the upload module is used by non-ssl downloads,
and perhaps allowing the abilitity to store for cache may be better that no-store, I went with what
was above suggested in this forum topic.

SO here is what the function looked like after patching:

function upload_file_download($file) {
  $file = file_create_path($file);
  $result = db_query("SELECT f.* FROM {files} f WHERE filepath = '%s'", $file);
  if ($file = db_fetch_object($result)) {
    if (user_access('view uploaded files')) {
      $node = node_load($file->nid);
      if (node_access('view', $node)) {
        $type = mime_header_encode($file->filemime);
// According to, MSIE needs to prevent caching for SSL download.
// Can use in return array 'Cache-Control' per
// Either Cache-control: no-store in headers, or use a max-age with must-revalidate?
// Cache-Control with no-store or max-age=60 and or must-revalidate directives appear to solve, however
// if a return includes the no-cache directive, it SHOULD NOT include max-age.
// Recommended return by Microsoft for SSL: 'Cache-Control: no-store',
// Recommended by some drupal users: 'Cache-Control: max-age=60, must-revalidate',
// Because this function is used also by non-ssl connections, some storing by cache may be better?
        return array(
          'Content-Type: '. $type,
          'Content-Length: '. $file->filesize,
          'Cache-Control: max-age=60, must-revalidate',
      else {
        return -1;
    else {
      return -1;

NOW we need others to bang on this and get the core developers to implement if satisfied!

Version:5.15» 5.18

Component:file system» upload.module

Version:6.x-dev» 5.18

I set the version to the latest, since that is what I am using and the bug is still present, and set the component to upload.module since that is what was discovered as having the bug.

After thinking some more, my question to the users, which variation of cache control would be best?

Maybe the Microsoft page was correct and we should use "no-store" instead of "must-revalidate" or "max-age"

MAYBE somehow the upload module should determine if HTTPS then IF it is https use the no-store in the return array, but don't use the no-store in the return array if it is http?

how could that be done elegantly?


have php use $_SERVER['HTTPS'] for the conditional and decide return array with that?

     if ($_SERVER['HTTPS']){
        return array(
          'Content-Type: '. $type,
          'Content-Length: '. $file->filesize,
          'Cache-Control: no-store',
     } else {
        return array(
          'Content-Type: '. $type,
          'Content-Length: '. $file->filesize,

BTW #2
after reading the microsoft knowledge base articles and version 5, 6, 7 and 8 of IE problems
I am still not sure which combination of 'no-store' 'no-cache' or whatever Cache-Control would be best.

Do we have any readers that are truly wizards at understanding the cache-control settings and
how best to optimize for MSIE and Firerox and others?

I do think now that part of the answer is that the function needs to return a different array if https than http and most the other posts elswhere have not mentioned this approach....

new1.35 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal5-uploadmodule-msie-fix-if-https.patch.
[ View ]

Here is the drupal 5 patch using the value of $_SERVER['HTTPS'] to add to the return array 'Cache-Control: no-store' if HTTPS is on.

For a SSL connection the browser should not store cache? And most likely Firefox and others just ignore that
the server did not tell them to not store the cache?

If all SSL downloads should not be cached by browsers, which I think is so, then the drupal module should use 'no-store' not max-age nor re-validate cache when doing an SSL download - correct?

Version:5.18» 6.x-dev

Let's see:

  • D7 standard cache header: Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
  • D6 standard cache header: Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
  • D5 standard cache header: Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0

Note that the store directive doesn't exist, and is causing issues studied in #197786: Some servers / browsers will cache pages even when header Cache-control: no-cache is set.

Supposing that store is the issue, I'm bumping that to D6. Can someone please test and confirm that removing the store directive solves the issue in affected versions of Internet Explorer?

Version:5.18» 6.x-dev

subscribing, Izzy

Version:6.x-dev» 6.13


I have a similar issue but with HTTP (no HTTPS): downloaded zip files with Internet Explorer 7 and 8 (no problem with firefox, opera and chrome) have an incorrect file size and they appear as corrupted.
I use Drupal 6.13 with the public download method.
I try with "no-store" configuration in but it doesn't solve my issue.
Do you have any fix for that?



I have a similar issue but with HTTP (no HTTPS): downloaded zip files with Internet Explorer 7 and 8 (no problem with firefox, opera and chrome) have an incorrect file size and they appear as corrupted.
I use Drupal 6.13 with the public download method.
I try with "no-store" configuration in but it doesn't solve my issue.
Do you have any fix for that?


I am on drupal 6 and using no-store worked for me.

Make sure you clear all your cache after you do this.

Version:6.13» 6.14


I just got the information from,the code is working on IE 7.0 under https ,the header information should like :

header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: private",false);

Version:6.14» 6.15

Still happening in 6.15

Version:6.15» 6.13

Confirm still happening in 6.13. Also confirm that adding the following headers definitely solved the problem in IE7 and 8, using a private file system, auth user, and no SSL, through IMCE:

Content-Disposition: attachment
Cache-Control: cache, store

I made the change in the IMCE module function that handles files downloads, but I imagine you may be able to set these headers elsewhere...

Cheers, Dakota

Version:6.13» 6.x-dev
Status:Active» Needs review
new953 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch ie-private-downloads-over-ssl-163445-35.patch.
[ View ]

This issue (unable to do private file downloads in IE over SSL) has a patch for HEAD over at

The patch, relevant for Drupal 6 is attached here. Needs review.

Status:Needs review» Reviewed & tested by the community

works well, 6.15 and 6.16 install bases on CentOS, using SSL. Tested with IE 6, 7, and 8.

mlsamuelson's patch works well on my 6.15

Component:upload.module» file.module

This bug persists in ie8, and the workaround in #3 is not effective.

The patch in #35 works perfectly in 6.16. any chance we can commit this, or does it have to go in d7 first?

Version:6.x-dev» 7.x-dev
Status:Reviewed & tested by the community» Patch (to be ported)

Let's get committed to Drupal 7 first as with our normal procedures.

Version:7.x-dev» 6.x-dev
Status:Patch (to be ported)» Postponed

The patch in #35 is for 6.x; there is already a patch ported for d7 at #181036: cannot download from https using IE.

Changing the status back; don't want anyone to spend time porting something that's already been ported. Apologies if I get this wrong... but marking this as 'postponed' (pending commit of #181036).

Status:Postponed» Closed (duplicate)

So this is a duplicate of #181036: cannot download from https using IE. I reviewed the patch there.

new908 bytes

Here is an update of the d6 patch, tested.

new959 bytes

I tested the patch in #42 with Open Atrium 1.0-beta7 (which includes Drupal 6.17) and it still had problems.

Before the patch: Firefox worked, IE was completely unable to download files.

After the patch: Both Firefox and IE prompted to download the file, but filename was empty in both cases.

The following modified version of the patch in #42 fixed the problem, even though it can likely be improved further.

wonder if this will be fixed in drupal 7,
this has been an issue for years

I'm not sure if this is the active thread to post to since it is marked "duplicate" as detailed in comment #41

I was puzzled because changing a Drupal 6.x site to private downloads on an ssl site did not give me problems with IE.

Reviewing the posts gave me the answer in comment #29 which says that using "no-store" solves this. This reminded me that the site has the "no-store" hack as described in to ensure privileged pages cannot be viewed after logout. I realize there is still a lot of controversy on that solution.

Yes, this is being tracked in #181036: cannot download from https using IE, but it has not been committed yet.

We've had this problem on our Drupal 6.17 site, which the patch in issue #43 fixed.

Since the thread mentioned in #46 ( seems to be a Drupal 7 thread, meaning the patches aren't applicable for Drupal 6, is it possible to apply the patch in this thread to Drupal 6 going forward?

Turns out the patch in #43 breaks swfobject embedded flash over https due to the Content-Disposition: attachment header.

I've implemented the patch from #42, which seems to work without fault.

Status:Closed (duplicate)» Reviewed & tested by the community

#42 seems to have solved the problem for me. thanks. i don't this is a duplicate. the other ticket is for d7 afaict. it should probably still get applied to d6 core.

#181036: cannot download from https using IE is for d7, but will not be committed because the issue was fixed by #898036: Private images broken.

So, the question is, what to do in d6? There are two choices; one would be to back-port #898036 to d6 (re-open as 'patch to be ported'), the other would be to commit #43 above to d6. #898036 introduces hook_file_download, which is more flexible, but is also a larger-impact change to d6. My opinion is that the patch on this issue is easier and sufficient.

Title:Internet Explorer cannot download/open files after upgrade to 5.2Internet Explorer cannot download private files
Status:Reviewed & tested by the community» Fixed

Ok, while reviewing this, it looked logical to have the two additional headers (from #42) to the $headers array, but after looking at the code more, it seems like it would be painful rather then useful to try and shoehorn it there. People could still override these two headers in the $headers array since that is processed later, so we should not loose customizability here.

So all in all, I've committed the patch from #42 and pushed to 6.x-dev. It should be fixed in the next stable Drupal version.


thanks... years in the fixing...

while this was not a critical issue, it has been a pain for private ssl websites.

thx for the fix, #43 did the trick for me

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

webengr, wickedwookie,

Is it fix for you? Can you explain how you did ?

I will explain you how i made:

1) I create an .htaccess to restrict the file download for users only & i placed it into sites/default/files wich contains:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks
SetEnvIfNoCase Referer "^http://www\.website\.be/" acces_local=1
<FilesMatch ".(pdf|xls|doc|docx|xlsx)">
Deny from all
Allow from env=acces_local
SetEnvIfNoCase Referer "^http://www\.website\.biz/" acces_local=1
<FilesMatch ".(pdf|xls|doc|docx|xlsx)">
Deny from all
Allow from env=acces_local

2) I placed the following patch into the includes/ like described on #43

+  // IE cannot download private files because it cannot store files downloaded
+  // over https in the browser cache. The problem can be solved by sending
+  // custom headers to IE. See
if (isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on')) {
drupal_set_header('Cache-Control: private');
drupal_set_header('Pragma: private');
drupal_set_header('Content-Disposition: attachment; filename="'.basename($source).'"');
   foreach ($headers as $header) {
     // To prevent HTTP header injection, we delete new lines that are

Does someone have any idea to help me ?

the patch was suppose to go into the core,
have you updated your drupal 6 or drupal 7, if using 5 DONT

btw, 6-22 and 7-2 came out yesterday I think.

Status:Closed (fixed)» Closed (won't fix)

Hi all!

I am experiencing this issue even if my Drupal core is updated to the 6.22 version. I recently switched my website to SSL and the problem of downloading attachments with IE 8 and private file system appeared. To add a bit of info, files attached to nodes as CCK filefield dowload regularly. Whed I try download node attachments clicking on the related link Explorer seems to load something and then stops without reporting any message... With Chrome and Firefox everything is OK.

I am quite a newbie so I hope to have been clear reporting the issue.


Version:6.x-dev» 6.22
Status:Closed (won't fix)» Active

Just thought I would leave a note for people who are running drupal behind an ssl offloader. I had to hack the file (hacking core is bad...etc.) to include a check for a header my reverse proxy set for me X-FORWARDED-PROTO. Hope this helps someone else.

if ((isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on')) || $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
drupal_set_header('Cache-Control: private');
drupal_set_header('Pragma: private');