On IE6 with a Drupal 4.7 install under https, certain attachment files such as swf and some office documents can't be served and IE gives the error:

Internet Explorer cannot download _file_ from server.
Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.

This is due to the bootstrap lines:

    header("Cache-Control: no-store, no-cache, must-revalidate");
    header("Pragma: no-cache");

See also: http://support.microsoft.com/kb/316431

I have tried searching for ways around this bug without touching the bootstrap to no avail, so I propose this change within filemanager.module (proposed changes have been prefixed with >>):

function filemanager_transfer($file, $working, $headers = FALSE) {
>>  global $base_url;

  $file = filemanager_get_file_info($file);
  $filepath = filemanager_create_path($file, $working);

  $default_headers = array(
    'Content-Type: '. $file->mimetype,
    'Content-Length: '. $file->size,
    'Content-Disposition: attachment; filename="'. $file->filename .'"'
  );

>>  // Get around the IE bug where files served under https must not be cached.
>>  // See Also: http://support.microsoft.com/kb/316431
>>  if (preg_match('|^https://|', $base_url)) {
>>    array_push($default_headers, 'Cache-Control: private', 'Pragma: private');
>>  }

Pushing these two headers in seems to override the ones the bootstrap sets. This fix should only be relevant for filemanager because it only affects attachments which need to be saved to disk so that IE plugins/activex controls can access the data.

Apologies if I have overlooked a blatantly obvious solution to this somewhere on this site. :)

CommentFileSizeAuthor
#2 filemanager.patch527 bytesDeciphered
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

miner’s picture

miner CreditAttribution: miner commented
Version: 4.7.x-1.x-dev » 5.x-1.x-dev

The same error happens with Filemanager 5.x-1.x-dev and Drupal 5.5.
By discussions in http://drupal.org/node/30525, the bug could be repaired by adding the following line to $default_headers:
'Expires: 0', 'Pragma: cache', 'Cache-Control: private
i.e.

  $default_headers = array(
    'Content-Type: '. $file->mimetype,
    'Content-Length: '. $file->size,
    'Content-Disposition: attachment; filename="'. $file->filename .'"',
    'Expires: 0', 'Pragma: cache', 'Cache-Control: private'
  );
Deciphered’s picture

Deciphered CreditAttribution: Deciphered commented
Status: Active » Needs review
FileSize
filemanager.patch527 bytes

Made a patch using the above fix, works on my end.

traxer’s picture

traxer CreditAttribution: traxer commented
Title: "Private" download method causes IE (incl. 7.0) to fail downloading attachments » Some attachments under https with Cache-Control/Pragma no-cache cannot be served under IE6

See also #213262: Opening ZIP files with Internet Explorer 6, Internet Explorer 7 (and IE 8) fails.

WorldFallz’s picture

WorldFallz CreditAttribution: WorldFallz commented

+1 for this patch. Tried and reviewed--- fixed this nagging bug for my site with no visible ill effects. I'm using Drupal 5.5 with a mixture of mostly IE6, some IE7, & very little FF. Seems ok for everyone so far.

roball’s picture

roball CreditAttribution: roball commented
Title: Some attachments under https with Cache-Control/Pragma no-cache cannot be served under IE6 » "Private" download method causes IE (incl. 7.0) to fail downloading attachments

Can confirm that Internet Explorer fails to download attachments (such as PDF files) under HTTPS *if* Drupal's download method has been set to private. This problem is not limited to IE versions < 7 - IE7 is affected as well! The "Private" method of Drupal 6.9 would send the "Cache-Control:" header "store, no-cache, must-revalidate, post-check=0, pre-check=0", which affects the bugs known by Microsoft in their browsers.

The simple solution is just not to use the private download method at all. The "Public" method just sends a "must-revalidate" "Cache-Control:" header, which works fine even with IE under HTTPS.

sikjoy’s picture

sikjoy CreditAttribution: sikjoy commented
Title: Some attachments under https with Cache-Control/Pragma no-cache cannot be served under IE6 » "Private" download method causes IE (incl. 7.0) to fail downloading attachments

Any ideas about how to get around this without sacrificing the security of the files? Making the files folder public is not an option for me.

I'm experiencing the same issue w/ IE8 & Drupal 6.14

roball’s picture

roball CreditAttribution: roball commented
Title: "Private" download method causes IE (incl. 7.0) to fail downloading attachments » "Private" download method causes IE (incl. 8.0) to fail downloading attachments

@sicjoy: Setting the download method to "Private" is really a bad idea - it causes more problems than this one. So I would recommend to go with "Public", disable core's "Upload" module at all and use the "WebFM" module for file upload and protection.

WorldFallz’s picture

WorldFallz CreditAttribution: WorldFallz commented

Somewhat off topic, but my current method is to set the drupal file system to public, use filefields for file storage, and make specific filefields private via the method described at http://drupal.org/node/189239.

I still have one d5 site using this module (which is the primary reason it hasn't been upgraded to d6 yet), but with filefield in core for d7 (along with both public and private options) I believe this module has seen end-of-life. Besides, there hasn't been a commit in over 2 years. :-(

dfylstra’s picture

dfylstra CreditAttribution: dfylstra commented

On our site with Drupal 6, users download Setup programs which are Windows executables, filename.exe, and these must be (or behave like) private downloads, served from /system/files/... Users with Internet Explorer 8, and some users (based on their reports) with IE 9, were getting exactly the message described above: "Unable to download filename.exe from www.mysite.com. Unable to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later."

There is a fix on the client side described at http://support.microsoft.com/kb/323308, but this involves changing Registry settings, which is a lot to expect from most users. In large companies, users often have older software (like IE8) and are forbidden to make changes like this.

What we did: used a hook_file_download function to override this header -- for Drupal-served files, it apparently is called early enough (before any headers are sent) so that PHP will replace the bootstrap.inc header with the newly supplied header (see http://php.net/manual/en/function.header.php, replace argument is true by default). So we use just this:

function mymodule_file_download($filepath) {
header("Cache-Control: private, must-revalidate");
}

IE is still basically a black box, but we're reasonably confident about this fix: We could reproduce the user-reported download problem with IE8 on a VM. When we made the Registry changes affecting IE on the client side as described in the Microsoft Knowledgebase article, the download problem was resolved. When we added the hook_file_download function above (and didn't make the Registry changes), the problem was also resolved. We have up to 1,000 downloads per day so if the problem was still occurring I believe we would hear about it.

Pomliane’s picture

Pomliane CreditAttribution: Pomliane commented
Status: Needs review » Closed (won't fix)

This version of Filemanager is not supported anymore. The issue is closed for this reason.
Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

This issue has been automagically closed by a script.