Whirlpool

Server running Apache 2.2.3, PHP 5.1.6.
We have an application that would generate csv file name and content for download on the fly.
The code is pretty simple, on the page if you click on the particular link, it'll run the php script that spits out the content.
The code is just something like this (from reports.php):

header('Content-type: text/csv');
header('Content-Disposition: attachment; filename=Sales.csv');

if ($start) {
print "Sales for period: $startDateTime ";
if ($end) {
print "to $endDateTime";
}
print "\r\n";
}

Pretty standard.
The code works fine, it'll prompt the user to download Sales.csv.
IE, however... would give me file not found error.

I found out that IE has the habit of ignoring that tag.
Adding

<IfModule mime_module>
TypesConfig /usr/local/apache2/conf/mime.types­
AddType text/csv .csv
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddType application/x-httpd-php .php .php3 .php4 .php5
AddType application/x-httpd-php-source .phps
AddHandler cgi-script .cgi
AddOutputFilterByType DEFLATE text/html text/plain text/xml
</IfModule>

to httpd.conf seems to help, now it downloads the content to reports.php instead of sales.csv. Any ideas?? :(

Don't send it as text/csv and: support.microsoft.com/kb/q279667

2. Add the HTML Response Headers for the file by using your Web Server software:
Content-Type = application/download
Content-Disposition = attachment; filename=test.txt

The Elite Geek writes...

Content-Type = application/download

WTF? So Microsoft's "fix" means you have to change the header so it's meaningless? The whole idea of a Content-Type is to tell the client what type of file it is!

For CSV, I've found text/comma-separated-values seems to work properly on IE. It was the de facto "standard" before RFC 4180.

I'd try application/ms-excel (?) actually, sending as text will ultimately cause IE to handle it as text (it seems).

Foonly writes...

WTF? So Microsoft's "fix" means you have to change the header so it's meaningless? The whole idea of a Content-Type is to tell the client what type of file it is!

And your surprised because Microsoft has never done anything dumb before? ;)

microsoft has always had trouble with the HTTP RFC... wait until you try downloading via SSL :)

after years and years (no kidding this is a longstanding battle with microsoft since about 1997 - we finally shook them down once to admit it was an architectural problem with MSIE, up to and including v6) of trial and error, this works for binary and text downloads, via http and https, under firefox and IE:

(unless you find otherwise, let me know)


// for download, not inline
header("Pragma: ");
header("Cache-Control: ");
header("Content-type: application/".$doc_type);
header("Content-Disposition: attachment; filename=\"$doc_name\";");
echo base64_decode($blob); // if you need binary
exit;

Thanks guys.
I'll give it a go, and if it works I'll make the recommendation to the dev team and see if they are happy with it. Strange thing, we move this application from a FreeBSD box, similar setup, and the apps worked fine there. :)

Snowy writes...

microsoft has always had trouble with the HTTP RFC... wait until you try downloading via SSL :)

Funny thing ;)
That is exactly what we're doing, the files are downloaded via ssl.
Thanks for all the suggestions here, but they don't seem to work.
I am now hunting down whether it is a problem with my httpd.conf.. :|

Jafar writes...

That is exactly what we're doing, the files are downloaded via ssl.
Thanks for all the suggestions here, but they don't seem to work.
I am now hunting down whether it is a problem with my httpd.conf.. :|

Have you tried firefox/opera?

I'm pretty certain this is a browser issue, not a server one.

Did you try what I suggested, esp with SSL, keeping Pragma and cache-control blank?

(just echo the csv output text instead of base64decode.)

What kinds of error/symptoms are you getting?