MSIE don't download well...

Anon

Hi!🙂
I have to implement a download system to handle also html and php files; so they can't be interpreted with the browser, but they need a 'download' dialog. I wrote the following, assumed $farg the name of the file to download, with path...

$fn=basename($farg);
if(strstr($HTTP_USER_AGENT, "MSIE"))
header("Content-Type: application/ms-x-download");
else
header("Content-Type: application/octet-stream");
header("Content-Length: ".filesize($farg));
header("Content-Disposition: attachment; filename=$fn");
header("Content-Transfer-Encoding: binary");
$fh = fopen($farg, "r");
fpassthru($fh);
fclose($fh);
unset($fh);

In netscape/Mozilla/Galeon it works, in MSIE it doesn't... it displays the dialog, but saves the file with the name of the php script this chunk is contained into, overriding (I guess) the Content-Disposition header...
How can I do? I guess there's a way, because around the net I see many of these services, working, but... how?
Thanks,
Mano 🙂

Anon

I have had a similar problem and also started
using the Content-Disp. header until I found
out MIE ignoring it.
After I quickly looked over the RFC for this
as far as I have understood this can only be used for multipart documents each providing its own header - e.g. a mail with binary attachments.
Correct me if I'm wrong.

After trying out this and that I finally ended up in the following solution:

Rather than pointing to actual the script for a download link to be displayed, e.g.
/download.php, I link to a URI that does not really exist and which does reference the file to be downloaded by its ID, e.g. /download.php/myfile.php?file_id=0815

Using apache I found it is smart enough to detect that the script to actually invoke is download.php, i.e. apache recognizes that /download.php/ is not a directory.
The file_id is passed to the script just as in the normal case though.

You can even detect what the dummy filename
was about by splitting the $REQUEST_URI if you need this.

For the content type I use application/octet-stream for simplicity as the file is meant to be downloaded anyway rather than being handled by an appropriate application. I did not use any additional http header, anyway, of course this might help browsers, e.g. giving hints about filesize etc. as you already have tries to.

When stupid MSIE 'sees' the link, it prompts you to download the file, providing the last path argument as the filename (myfile.php)
whereas apache invokes the last path argument which indeed is a script (download.php).

In my case the files come from the server filesystem (in directories being out of apache'r reach in order to implement an access control system), but this should work also for files coming from e.g. a database.

I tested this also with NS (Win/Unix), Konqueror and several BeOS Browsers, therefore I consider this procedure working in general.

Art

Anon

(not sure about this)
if you supply the filename as the last argument it will save as that name:

only use the header("Content-Type: application/octet-stream"); (sure about this 🙂, since other header like cont-disp will be ignored because they are headers used in mime email messages)

Anon

i do it like this

header("Content-type: application/octet-stream");
if(!(strpos($HTTP_USER_AGENT,"compatible"))){header("Content-Disposition: attachment;");} # Netscape
header("Content-Disposition: filename=install.php");
header("Content-Transfer-Encoding: binary");

works fine for me.

Anon

Thanks Art! you just ended my 4 hour search for a solution.

What a mission just to try and find out why M$ IE doesn't want to work!