Opening ZIP files with Internet Explorer 6, Internet Explorer 7 (and IE 8) fails

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.

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.

sorry - didn't mean to make critical

Just tested:

Content-Length: 63262
Content-Type: application/x-zip-compressed

Attached patch adds a sentence to the public/private radio buttons:

Due to a bug in Internet Explorer 6 and earlier versions, the Private download of ZIP files does not work reliably with these browsers, see http://support.microsoft.com/kb/308090 for details.

are the headers the same for public and private?

If you want to tell your users, there is the option to override theme_upload_attachments. Here is a replacement for the return-statement:

if (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'));
}

I've nailed the problem down to the Cache-Control header. The patch uses Cache-Control: private instead of Cache-Control: no-cache for 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_match is used for PHP4 compatibility.

See also #163298: "Private" download method causes IE (incl. 8.0) to fail downloading attachments.

subscribe

I have Internet Explorer 6. What steps do I need to test, pre and post patch, to review this?

Rather than working around the bugs in specific browsers, wouldn't it be better to switch from "no-cache" to "private" altogether?

• Keeps the code cleaner.
• "must-revalidate" takes care that no old content gets to the browser.

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.

It also fails for PDF files, even with newer versions of Internet Explorer. Suggest patch.

I believe the patch at #17 is for Drupal 7. The attached patch applies the same idea to Drupal 6.

Note that this problem also affects PDF downloads in IE 7 (haven't tried IE 8, but I wouldn't be surprised), so we can't just hope the problem will go away as IE 6 use declines. I imagine IE 7 will be around for a while to come. The patch solves the problem for a Drupal 6 site with private files being downloaded to XP/IE 7.

Subscribing.

Would love to see the priority of this issue raised.

My clients (using private file system) are seeing .zip file corruption with IE6, 7, and 8.

Subscribe - First I heard of this. However I surf with Firefox.

We have one client that is extensively using Private file attachments. PDF and ZIP files are in the mix. Once the Drupal version of the site goes live, I guess I can expect to hear gripes from those surfing with IE. hhhmmmm....

I applied the patch in #18 and it didn't help my problem.

The actual message I get when I try do download and uncompress a .zip file is, "The Compressed (zipped) Folder is invalid or corrupted."

If I right-click and "save target as" the download works fine.

Download works fine with Firefox.

Site is http (not https).
Download method is Private.
Target download is in .zip format
Browser is Internet Explorer v8.0.6001.18702

Changing title to reflect that this issue also impacts users of Internet Explorer 8 (I don't have IE 7 to test against).

This is happening to me as well. It works fine in Firefox, but when downloading the same exact file in IE 8 it gives me the error message. I'm using Windows 7.

Error: "Cannot open file: it does not appear to be a valid archive. If you downloaded this file, try downloading the file again."
(I click okay)
Errors occurred while extracting. Do you want to view the last output? (I click yes)
"End-of-central-directory signature not found. Either this file is not a Zip file, or it constitutes one disk of a multi-part Zip file."

It happens whether I click open or save.

These are the headers that we have (I didn't write this code so I'm not really sure what all the different items in the header mean) :

//ZipArchive code above

if(ini_get('zlib.output_compression')) { ini_set('zlib.output_compression', 'Off'); }

header('Pragma: public');   
header('Expires: 0');      
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header('Cache-Control: private',false);
header('Content-Type: application/zip');
header('Content-Disposition: attachment; filename="'.basename($filename).'"');
header('Content-Transfer-Encoding: binary');
header('Content-Length: '.filesize($filename)); 
readfile($filename);

Any advice would be helpful..

We are having the same issue with Drupal 6.17, anyone found a way to really fix this?

subscribing

Experiencing invalid zip downloads with IE 7 & 8 on Windows 7 with the download method set to public (Drupal 6.19). Is there a fix for this?

Is there a resolution to this issue with IE?

Slightly related fix: http://drupal.org/node/820464#comment-3495478

This is not only a Drupal bug. It also affects IIS 7 and at least IE8. Same exact symptoms. User downloads zip file w/ IE and the size is larger than it should be and the zip file won't open. Same exact file downloaded via Chrome or Firefox works fine.

I moved the zip file to an apache server running on Fedora, and it downloaded fine in IE.

Appears to be a bug that affects various versions of IE and some specific web servers. Just thought I would share the extra info as a search for my issue turned up this thread.

First time experiencing this issue. Glad to see it is fixed in IE9 but for now I did a simple work-around. I added the below to .htaccess

<FilesMatch "\.(?i:zip)$">
  ForceType application/octet-stream
  Header set Content-Disposition attachment
</FilesMatch>

@mikinho #34

Adding your suggested entries to the .htaccess of Apache 2.2.8 running on Ubuntu 8.04 causes the entire site to get 500 errors. I guess your suggestion also needs a bit of testing.

Thank you, that fixed the problem for us. We have our site on a shared host and updating the server was really not an option, but the .htaccess is available to us. I expect that the problem will be less of an issue as the general Microsoft OS platform users migrate to Win7 which now includes IE9 by default, but until then, this works.

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 this message: "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."

The problem is IE-specific and is documented at http://support.microsoft.com/kb/323308, but in our experience it applies to both https and http downloads, if the server is sending "Cache-control:no-store" or "Cache-control:no-cache". Drupal's bootstrap.inc contains:

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

We used a hook_file_download function to override this header; for Drupal-served files, it evidently is called early enough (before any headers are sent) so that PHP will replace the bootstrap.inc header with the newly supplied header. 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 at http://support.microsoft.com/kb/323308, the download problem was resolved -- but of course our users cannot be expected to do this. 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'm pretty sure we would hear about it.