Opening ZIP files with Internet Explorer 6 fails
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | file system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Our setup: Windows 2000 Server ; Apache 2.0.61 ; PHP 5.2.5 ; MySQL 5.0.45 ; Drupal 5.6 ; private file system.
We use the core 'Upload' module to manage attachments that we offer for downloading on our web site. Since a few Drupal releases, people using Internet Explorer 6 have experienced problems downloading ZIP files. The problem only shows up when, after clicking on the download link, the person selects "Open file" in the window that pops up. The ZIP file then shows up as being empty with no file inside. When selecting "Save as...", saving the file somewhere on the hard disk and then opening the ZIP file from there, it works OK.
I have run some tests, with the following combinations of OSes and web browsers, in each case selecting the direct "Open file" option after having clicked on the file download link:
1) Windows 2000 + Internet Explorer 6 + Winzip 8.1 SR1: fails
2) Windows XP + Firefox 2.0.0.11 + Winzip 8.1 SR1: works OK
3) Windows XP + Opera 9.25 + Winzip 8.1 SR1: works OK
4) Windows XP + Safari 3.0.4 + Winzip 8.1 SR1: works OK
5) Windows XP + Internet Explorer 6 + Winzip 8.1 SR1: fails
6) Windows XP + Internet Explorer 7 + Winzip 8.1 SR1: works OK
7) Windows Vista + Internet Explorer 7 + built-in feature to open compressed folders: works OK
8) Windows Server 2003 + Internet Explorer 7 + Winzip 8.1 SR1: works OK
The results are the same with either clean URLs turned on or off.
Having access to another server, I have conducted a quick test with the following setup: OpenBSD 4.2 server ; Apache 1.3.19 ; php 5.2.3 ; MySQL 5.0.45 ; Drupal 5.6 ; private file system ; Clean URLs.
=> same results with Windows XP + Internet Explorer 6 + Winzip 8.1 SR1: it fails.
I have then uninstalled Winzip 8.1, and have rerun the attempt to download the file and open it directly (Windows XP + Internet Explorer 6). Windows then identifies the file as a compressed folder, and displays an error message saying that the ZIP file is corrupted or invalid.... which it is not...
After having uninstalled Winzip 8.1, I rerun the test having zip compressed the file again using WinRAR 3.71. The problem is the same: Internet Explorer 6 returns a 'compressed folder corrupted' error message when trying to open it directly after having clicked on the download link. So I can rule out the fact that there was an issue with the software used to create ZIP files at our end (Winzip 8.1 or WinRAR 3.71).
One last test I performed, was to FTP the ZIP file at the root of the Drupal install directory, and then try to download it using the direct URL: http:example.com/test.zip (therefore bypassing the Drupal private file system method): the download worke fine.
So to summarize:
* tested on 5 different end-user computers with 3 differents OSes (XP + 2000 + Vista)
* tested on 2 different servers (Windows 2000 + OpenBSD 4.2)
* Zip file created with 2 differents software (Winzip 8.1 or WinRAR 3.71)
* clean URLs turned on or off
* tested with 5 different browsers
=> internet explorer 6 (on XP and Win2000), a still widely used browser, is the only one to have the problem, and it apparently relates to using the Drupal file system (bypassing the drupal file system works OK).
I would be glad if someone could reproduce the issue to confirm it. I have made every effort to ensure that my tests were done correctly (cache + temp internet file folders emptied in between tests, etc) but I may have forgotten something.
#1
Following-up, I have made a few more tests:
1) switching the file system from 'private' to 'public' solves the problem. So apparently it is an issue only with the private file system.
2) as I had put the content of .htaccess in httpd.conf, I have reverted to using the default .htaccess file as in a default Drupal install. The problem is still there, so the problem is not with the code I had put in httpd.conf apparently.
3) I have now installed a test site using the latest Drupal 6.0-rc2 codebase on the Windows 2000 Server with Apache 2.0.61 ; PHP 5.2.5 ; MySQL 5.0.45 ; configured with private file system ; default .htaccess file ; NO clean URLs.
The problem is still there: on Windows XP, using Internet Explorer 6 and selecting 'Open' after having clicked on the download link, Winzip opens an empty ZIP file with nothing inside. At the same time it works fine with Firefox 2.0.0.11 (I haven't redone the tests with the other combinations of OS/browser).
I am therefore updating this issue to concern Drupal 6.0-rc2, but note that it concerns also Drupal 5.6 on my side.
#2
This is a bug in Internet Explorer. Judging from http://support.microsoft.com/kb/308090, the only solution I can think of is, to copy the Zip-File to a location where it can be downloaded without being served by Drupal.
Ugh ... that could be messy.
I changed the priority because over time, fewer users will be affected and only the private method breaks the download.
#3
sounds like upload_file_download() needs to change the http headers it outputs for .zip (probably Content-Type).
You should use wireshark or similar to log the http headers for public and private downloading of a .zip.
#4
sorry - didn't mean to make critical
#5
Just tested:
Content-Length: 63262Content-Type: application/x-zip-compressed
Attached patch adds a sentence to the public/private radio buttons:
#6
are the headers the same for public and private?
#7
The proposed patch is great for alerting administrators when they configure the file system of new sites, but existing sites using the 'private' method with a large number of files are stuck, as switching private => public may not be an option due to the large number of links that may break. And the problem may concern quite a number of users (on one of our sites, 37% of our users still used IE6 for example vs. 32% for IE7 in December).
Just a thought: in case patching to solve the issue is not possible at Drupal's end, what about displaying also a warning message for users at the top or bottom of nodes which include ZIP file attachments when the private method is used ? Such a message could read :
#8
If you want to tell your users, there is the option to override theme_upload_attachments. Here is a replacement for the
return-statement:<?phpif (variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC) == FILE_DOWNLOADS_PRIVATE) {
return theme('table', $header, $rows, array('id' => 'attachments'))
. '<div class="description">'
. t('If opening a file directly does not work, save the file to your computer first.')
. '</div>';
} else {
return theme('table', $header, $rows, array('id' => 'attachments'));
}
?>
#9
I've nailed the problem down to the Cache-Control header. The patch uses
Cache-Control: privateinstead ofCache-Control: no-cachefor private file downloads. Tested on Windows XP with Internet Explorer 6.The patch does not change the cache-control header if one is supplied by hook_file_download.
preg_matchis used for PHP4 compatibility.See also #163298: "Private" download method causes IE (incl. 8.0) to fail downloading attachments.
#10
Server: Windows 2000, Drupal 6.0-rc2, php-5.2.5, mysql 5.0.45, Clean URLs, private file system.
Patch tested and working fine with:
Windows XP + Internet Explorer 6
Windows 2000 + Internet Explorer 6
Also tested with:
Windows XP + Firefox 2.0.0.11
Windows XP + Opera 9.25
Windows XP + Safari 3.0.4
Windows Server 2003 + Internet Explorer 7
It works perfectly in all cases as far as I am concerned. Good work, thanks !
#11
subscribe
#12
I have Internet Explorer 6. What steps do I need to test, pre and post patch, to review this?
#13
Any possibility to include the patch in the next maintenance releases of Drupal 6 (6.2) and 5 (5.8) ?
#14
(this is in reply to comment #12 above)
You should download and install a website with Drupal 6.1, configure it to use the private download method, or use an existing drupal site already configured to use the private download method (DO NOT switch an existing site from using the public download method to using the private one, or it will break a few things).
Then:
1) create a node which includes as an attachment a ZIP file, then try to click on the download link in IE6 and 'open' the file directly. It should fail (empty ZIP file when opening it with Winzip)
2) merge the patch in #9 above in the file.inc file of the INCLUDES sub-directory of your Drupal site, and re-run the test. It should then work.
#15
Rather than working around the bugs in specific browsers, wouldn't it be better to switch from "no-cache" to "private" altogether?
However, I don't know how closely common browsers and proxies follow the HTTP specification (specifically "must-revalidate"). I would be thankful for advice on this subject.
#16
As the person who opened this 'issue', I feel I should probably follow up. Many thanks to Traxer for the time spent on the issue and the patch proposed. I am unfortunately not a developer and definitely not skilled enough to provide significant input on the technical side of things.
I am personally losing interest in the issue as we are officially no longer supporting IE6 on our websites, with a banner being added to the pages for people browsing with IE6 strongly encouraging them to upgrade (it is impressive to see in the stats the still large number of people still using IE6 nowadays). So let's clear the queue of pending issues after nearly one and a half year without further input/action on this one. I propose to close it. Anybody with a need for a fix, a strong feeling on the issue and patience to have it reopened, please feel free ;-)