Help. It does not work! :-)

To be precise with perl 5.8.8 and the latest Apache 2.2 on win 32 the following behaviour is observed:

After a default Apache install, using Firefox, browsing to:

http://localhost/cgi-bin/printenv.pl

works as expected and dumps the enironment to the browser. HOWEVER going to the same URL with IE 7 results in the script being downloaded! WTF??? Why is Apache executing the script for Firefox but sending it as a download to IE??? If I make a copy of this default script and rename it .cgi then it works as expected with both Firefox and IE ie http://localhost/cgi-bin/printenv.cgi dumps the env to the browser. Investigations and results (nope = download script to browser, not output)

1. telnet localhost 80 GET /cgi-bin/printenv.pl HTTP/1.0\n\n -> WORKS as expected (env output)
2. Remove and reinstal Apache - tried versions 2.0 and 2.2 with and without SSL -> nope
3. Cleared the IE cache, closed it down, rebooted, tried again - nope
4. Added a query string http://localhost/cgi-bin/printenv.pl?foo=bar - nope
5. Added path/info so http://localhost/cgi-bin/printenv.pl/extra/path - WORKS
6. Accessed via http://127.0.0.1/cgi-bin/printenv.pl - nope
7. Accessed via http://192.168.1.4/cgi-bin/prinenv.pl - nope
8. Added and removed (from the appropriate places) with the appropriate apache restart. Note httpd.conf file is vanilla default from fresh install.
   • Options ExecCGI
   • AddHandler cgi-script .pl .cgi

This makes no sense to me. It does not seem to be a caching issue - normally adding a new query string or accessing via a diferent URL will cure this but it does not. As noted I even resorted to a reboot post a cache clean.

Apache should know to execute the script and indeed it does as proven by it working with either telnet or Firefox. Why is it downloading the script to IE? Why does it behave correctly if I add /path/info onto the end?

This is in no way mission critical but I would like to get it to behave.

Update

Thanks to everyone who chipped in. Although it appears to be the perl script being downloaded it is in fact the output of the script. Thanks mwah The issue is the Content-Type: text/plain header which IE is ignoring, choosing instead to try and execute the plain text output as a perl file locally. Changing to text/html fixes the problem. I would really have loved to hear the argument (if there was one) at M$ when some engineer evidently put forward the view that it would be more efficient to ignore the MIME type and take a stab in the dark using some heuristics instead. The link to the M$ article from AM is enlightening. Even if you set the IsTextPlainHonored registry key IE reserves the right to ignore it!