Content-Disposition... odd behavior in IE

[Rodster001]

Greetings!

I am having some problems with IE and how it is handling the Content-Disposition header (I am not the first as it would seem).

When clicking a link in a web page with a CGI that returns the Content-Disposition header, IE will display a dialogue box "Save Open Cancel". Save works fine (saving the file and then opening works). Open, however will open the helper application but the file is always not found.

I have done some searching on the Net about this and found a few posted topics but no answers. Any ideas? Workarounds?

Here is a stripped down sample HTML page and CGI so you can reproduce the error and see for yourself.

test.html:

<a href="test.cgi">Download</a>

test.cgi:

#!/usr/bin/perl
use strict;
print "Content-type: application/octet-stream\n";
print "Content-disposition: attachment; filename=big-test.csv\n\n";
print "Test,One,Two,Three\n";
exit;

Note: For this error to be produced as I am explaining it, you need both the HTML and CGI file. Opening the CGI directly in IE produces different results. Also, the Content-type header can be omitted and produces the same results. I won't bother mentioning that this works fine in Firefox... oh, oops ;)

As always, thank you in advance for any enlightenment!

[ikegami]

You really should include the name of the file you are trying to open in the error message you output. I bet you are trying to open

C:\Documents

instead of

C:\Documents and Settings\...\big-test[1].csv

I changed .csv to .txt (since .csv isn't associated with anything on my machine) and it works fine for me in IE6. Are you sure your association is correct? Note the quotes around the %1:

"C:\Program Files\editor\editor.exe" "%1"

[tilly]

I don't have IE to test with, but based on a Google search the following has a good chance of fixing it.

#!/usr/bin/perl
use strict;
print "Content-type: application/octet-stream\n";
print "Cache-Control: private\n";
print "Content-disposition: attachment; filename=big-test.csv\n\n";
print "Test,One,Two,Three\n";
exit;

(This is based on this experience someone else had.)

[Rodster001]

No dice :(

The Cache-Control header didn't change a thing. But it does seem to be something to do with the cache. Almost like IE is deleting the file immediately after it creates it.

[tilly]

Perhaps capitalization matters?

#!/usr/bin/perl
use strict;
print "Content-type: application/octet-stream\n";
print "Cache-Control: private\n";
print "Content-Disposition: attachment; filename=big-test.csv\n\n";
print "Test,One,Two,Three\n";
exit;

Update: And if that doesn't work, perhaps

#!/usr/bin/perl
use strict;
print "Pragma: \n";
print "Cache-Control: \n";
print "Content-Disposition: attachment; filename=\"big-test.csv\"\n";
print "Content-type: application/octet-stream\n\n";
print "Test,One,Two,Three\n";
exit;

(It is frustrating that I can't test these suggestions, but I don't have IE to test with and it is a browser issue.)

[assemble]

I tested the code and it appears to work fine. Perhaps there is some setting in your IE that's been changed to not allow it?

Have you tried this on somebody else's computer?

[Rodster001]

Yeah, I have gone around in the office and *most* of the computers here are doing the same thing (I tested 6, one could open the Excel docs, csv but not Acrobat, pdf. All the rest are doing what mine is). We are all running the same versions of IE too. This really sucks.

Update: So, testing different file extensions and different computers produces a very wide range of results and all of which are very inconsistent (which is no good). My conclusion: This header's implementation in IE is not too reliable :)

[ikegami]

Given that the problem doesn't depend on the version of IE and it does depend on the extension, my suspicion that the associations on your computers are broken is looking extremely likely.