"Private" download method causes IE (incl. 8.0) to fail downloading attachments
| Project: | Filemanager |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
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. :)
#1
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: privatei.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'
);
#2
Made a patch using the above fix, works on my end.
#3
See also #213262: Opening ZIP files with Internet Explorer 6 fails.
#4
+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.
#5
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.
#6
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
#7
@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.
#8
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. :-(