This is a problem with IE, due to the (stupid) way that it handles temporary downloads with cache controls enabled. Until we can get the time to "fix" this with a workaround in the caching headers, the current solution for IE users is to always select "Save As" from the download dialog, rather than "Open With".

I did a test with "Save As" and got the same result. Is there anything else I could try?

(*Note: I have recommended the use of a different browser to our users, but most prefer IE.)

Is this issue related with 0009775 ?

We are now using V1.1.8, but we still have the same issue w/ downloads from IE (IE6 & IE8 tested so far).

I've tested this issue with attachments that have spaces and those that don't and get the same error. Therefore, I don't think this issue is related to 0009775.

In case it helps.

I was able to download TXT & CSV files in IE. Errors still occur on other filetypes (PDF, XLS,DOC).

Another piece to the puzzle: This problem only occurs when using IE over SSL. Downloads done using IE without SSL enabled were successful.

As described here: http://support.microsoft.com/kb/323308 don't send headers "Cache-control:no-store" and "Cache-control:no-cache" by mantis and by SERVER.

On my nginx server I have global directive "expires 1y" (that add "Expires" and "Cache-control" headers) and set "expires off" (that remove "Expires" and "Cache-control" headers) for *.php files and this fixed incorrect downloading.

But don't set "expires -1" for preventing caching: this add "Cache-control: no-cache" header that breaking downloading in IE over SSL.

can you please tell us where we can change the Cache-control?

Thanks

The problem which I met is a little different. The large file (*.rar, over 5MB) can be uploaded successfully and it stores in the server disk. However, when the large file is downloaded, the file size is always zero (IE/Firefox/Chrome are all the same).

My Mantis version is 1.2.0 rc1.

Is there any patch or configuration should be modified? Thanks!

In our installation, this appeared in 1.1.6 on Debian lenny. "Save as" didn't work either.

The cause was the use of a server-side proxy server. The client connects to the proxy with https, but the proxy forwards the connection with http. Now mantis thinks IE has no problem with the "Pragma: no-cache" http header and sends it.

I've added a configuration variable $g_always_assume_https which makes mantis think the connection is https even if it is not, so the IE hack avoiding the pragma is always active.

In /etc/mantis/config_local.php I added
$g_always_assume_https = true;

The following patch shows the difference in file_download.php:

--- file_download.php.dist 2009-10-21 11:13:49.000000000 +0200
+++ file_download.php 2009-10-21 11:20:02.000000000 +0200
@@ -105,7 +105,7 @@

attached files via HTTPS, we disable the "Pragma: no-cache"

    # command when IE is used over HTTPS.
    global $g_allow_file_cache;

• if ( ( isset( $_SERVER["HTTPS"] ) && ( "on" == strtolower( $_SERVER["HTTPS"] ) ) ) && preg_match( "/MSIE/", $_SERVER["HTTP_USER_AGENT"] ) ) {
• if ( ( ( isset( $_SERVER["HTTPS"] ) && ( "on" == strtolower( $_SERVER["HTTPS"] ) ) ) || $g_always_assume_https == true ) && preg_match( "/MSIE/", $_SERVER["HTTP_USER_AGENT"] ) ) {

  Suppress "Pragma: no-cache" header.

  } else {
          if ( ! isset( $g_allow_file_cache ) ) {

Good luck,
Moritz

I think I may have fixed this in 0011075

Can someone please test my patch?

(snapshot @ http://git.mantisbt.org/?p=mantisbt.git;a=snapshot;h=07c8da02a96216b87842190cca2777e82a668d1f;sf=tgz)

The patch in issue 0011082 (also 011075) worked for me (1.2.0rc2).

is there a reason this bug isn't linked to 0011075 and closed out? Or are you still waiting for the original reporter to confirm the patch worked for them?

Sorry, I wasn't waiting... I just didn't see the update to this issue.

I've marked this as a duplicate of 0011075 as we've received feedback that 0011075 fixes this issue.