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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

whelm’s picture

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

whelm’s picture

This problem is still present in 5.3

joep.hendrix’s picture

FileSize
21.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.

Joep

webengr’s picture

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

webengr’s picture

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

webengr’s picture

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:

http://drupal.org/node/254939

alpritt’s picture

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?

webengr’s picture

Version: 5.15 » 5.7

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

NOTE TOOK WEBSITES DOWN, MAY2009, IF NEED TEST WEBSITES BACKUP LET ME KNOW

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 http://drupal.org/drupal-5.x-dev 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)

http://64.129.81.185/ (redirects to https)
or
https://64.129.81.185/

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

http://64.129.81.186/ (redirects to https)
or
https://64.129.81.186/

user: test
password: abc123

YES THE BUG EXISTS for MSIE 6

----------------------------

FOR 7.x DEV 2008-Jun-11

http://64.129.81.187/ (redirects to https)
or
https://64.129.81.187/

user: test
password: abc123

COULD NOT TEST DUE TO DEV ERROR
notice: Undefined variable: file in ***/drupal-7.x-dev/modules/upload/upload.module on line 151.

webengr’s picture

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 ?

bander2’s picture

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.

webengr’s picture

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.

nerdoc’s picture

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

drumming_cat’s picture

Version: 5.7 » 5.15

Hi,

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,
Natascha

drumming_cat’s picture

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.

webengr’s picture

Version: 5.7 » 5.15

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

Are you referring to ./includes/file.inc

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.
AND POSSIBLY AOL

bander2’s picture

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.

johnhanley’s picture

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.

webengr’s picture

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

johnhanley’s picture

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

webengr’s picture

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:
http://support.microsoft.com/kb/815313

And here is the w3 page explaining Cache-Control:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

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 http://support.microsoft.com/kb/815313, MSIE needs to prevent caching for SSL download.
// Can use in return array 'Cache-Control' per http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
// 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!

webengr’s picture

Version: 5.15 » 5.18
webengr’s picture

Component: file system » upload.module
webengr’s picture

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?

maybe
http://www.wallpaperama.com/forums/how-to-detect-if-url-is-secured-ssl-w...

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

webengr’s picture

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.

QUESTION:
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?

Damien Tournoud’s picture

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?

izmeez’s picture

Version: 5.18 » 6.x-dev

subscribing, Izzy

jerome@drupal.org’s picture

Version: 6.x-dev » 6.13

hi,

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 bootstrap.inc but it doesn't solve my issue.
Do you have any fix for that?

bye
Jerome

jerome@drupal.org’s picture

hi,

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 bootstrap.inc but it doesn't solve my issue.
Do you have any fix for that?

bye
Jerome

xamox’s picture

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

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

bigdave’s picture

Version: 6.13 » 6.14
mrfelton’s picture

Subscribing.

qianbc2007’s picture

I just got the information from PHP.net,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);

bigdave’s picture

Version: 6.14 » 6.15

Still happening in 6.15

dakotaryan’s picture

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

mlsamuelson’s picture

Version: 6.13 » 6.x-dev
Status: Active » Needs review
FileSize
953 bytes

This issue (unable to do private file downloads in IE over SSL) has a patch for HEAD over at http://drupal.org/node/181036.

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

dilvish’s picture

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.

heyqule’s picture

mlsamuelson's patch works well on my 6.15

greg.1.anderson’s picture

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?

Gábor Hojtsy’s picture

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.

greg.1.anderson’s picture

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

Damien Tournoud’s picture

Status: Postponed » Closed (duplicate)

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

greg.1.anderson’s picture

Here is an update of the d6 patch, tested.

pescetti’s picture

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.

webengr’s picture

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

izmeez’s picture

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 http://drupal.org/node/197786#comment-1055633 to ensure privileged pages cannot be viewed after logout. I realize there is still a lot of controversy on that solution.

greg.1.anderson’s picture

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

mdelahoyde’s picture

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

Since the thread mentioned in #46 (http://drupal.org/node/181036) 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?

mdelahoyde’s picture

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.

Ron Collins’s picture

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.

greg.1.anderson’s picture

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

Gábor Hojtsy’s picture

Title: Internet Explorer cannot download/open files after upgrade to 5.2 » Internet 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.

greg.1.anderson’s picture

Thanks!

webengr’s picture

thanks... years in the fixing...

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

wickedwookie’s picture

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

Status: Fixed » Closed (fixed)

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

ChristopheMaertens’s picture

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
</FilesMatch>

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

2) I placed the following patch into the includes/file.inc 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 http://support.microsoft.com/kb/323308/en-us
 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 ?

webengr’s picture

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.

cyberto’s picture

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.

Thanks

cyberto’s picture

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

Just thought I would leave a note for people who are running drupal behind an ssl offloader. I had to hack the files.inc 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');
}

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.