Re: Content-Type not working on MSIE
Hi Andrew, Andrew Ho wrote: [...] Sometimes, MSIE will ignore the MIME type specified in a Content-Type header, and instead guess the type of a file based on its extension. [...] I _believe_ the answer lies in http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp. Basically, MSIE deliberately goes out and tries to figure out the real MIME type of 26 hardcoded MIME types. John -- +I speak for myself.+ | John Jung ([EMAIL PROTECTED]) | EDS | | Global Technical Access Center| 10824 Hope Street, Cypress Pointe | | Operating Systems Group | Cypress, California 90630 | +--(800) 955----+
Re: Content-Type not working on MSIE
Andrew Ho wrote: Hello, SBCan someone please summarize the problem and add possible solutions and SBpost it here so we can add it to this document: SBhttp://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html Sometimes, MSIE will ignore the MIME type specified in a Content-Type header nice recap andrew :) we mention the problem briefly, as well as the three solutions you offer, in the cookbook, Recipe 5.6. Using the URI to Force a MIME Type maybe a pointer there is a good thing to have too :) --Geoff
RE: Content-Type not working on MSIE
Greetings. [...] The issue: The simplest script I can't think of doesn't work. my $r = shift; $r-send_http_header(text/plain); $r-print(hello world); When I try to access the script, my MSIE 6.0 prompts for download when it should simple print the hello world string. Isn't it? [...] Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /perl/test.pl HTTP/1.0 [...] What I'm doing wrong?? I do not think it is you. But, I have observed that IE sometimes tries to outfox Content-type when the extension of the url maps to one of the locally registered file types. Therefore, if perl (AS) is installed on the client machine, IE will disregard Content-type in favor of the local file association. If this is the case, then changing the extension from .pl to (nothing) should give you the expected result, as would requesting /perl/test.pl?foo=bar instead than /perl/test.pl. As an aside, if anyone on the list knows of ways to defang this really annoying IE behavior, I would be most interested in knowing about it Cheers, alf
RE: Content-Type not working on MSIE
Hello, AFAs an aside, if anyone on the list knows of ways to defang this really AFannoying IE behavior, I would be most interested in knowing about it Two (and probably more) ways to do it. This is probably in a FAQ somewhere as it is a common problem. (1) Fool IE by snarfing another extension in the URL. For example, instead of requesting http://www.example.com/foo.pl, tack on a dummy parameter and request http://www.example.com/foo.pl?filename=foo.txt. (2) Send a Content-Disposition header. This is a MIME header and not in the HTTP spec but IE respects it: Content-Disposition: inline; filename=foo.txt Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Content-Type not working on MSIE
On Thu, Mar 20, 2003 at 02:04:55PM -0800, Andrew Ho wrote: Hello, AFAs an aside, if anyone on the list knows of ways to defang this really AFannoying IE behavior, I would be most interested in knowing about it Two (and probably more) ways to do it. This is probably in a FAQ somewhere as it is a common problem. (1) Fool IE by snarfing another extension in the URL. For example, instead of requesting http://www.example.com/foo.pl, tack on a dummy parameter and request http://www.example.com/foo.pl?filename=foo.txt. I don't think this works with everything. (2) Send a Content-Disposition header. This is a MIME header and not in the HTTP spec but IE respects it: Content-Disposition: inline; filename=foo.txt I know that this doesn't work for all browsers. Our solution was to do a simple path info that was basically irrelevent. http://foo.bar.com/path/to/fetchfile.pl/foobar.pdf Every browser we tested it on tried to save the file as foobar.pdf. Rob
Re: Content-Type not working on MSIE
Robert Landrum wrote: On Thu, Mar 20, 2003 at 02:04:55PM -0800, Andrew Ho wrote: Hello, AFAs an aside, if anyone on the list knows of ways to defang this really AFannoying IE behavior, I would be most interested in knowing about it Two (and probably more) ways to do it. This is probably in a FAQ somewhere as it is a common problem. Can someone please summarize the problem and add possible solutions and post it here so we can add it to this document: http://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html I think this doc should be renamed to ie_bugs.html ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Content-Type not working on MSIE
Hello,
SBCan someone please summarize the problem and add possible solutions and
SBpost it here so we can add it to this document:
SBhttp://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html
Sometimes, MSIE will ignore the MIME type specified in a Content-Type
header, and instead guess the type of a file based on its extension. For
example, on most Windows systems files with a .reg extension are registry
files. So if you happen to have a Perl script on your mod_perl webserver
called foo.reg, even if it outputs a Content-Type: text/plain webserver,
MSIE may treat the output from the URL as a registry file (and pop up a
dialog box asking if you want to run the file, e.g., attempt to merge
its contents with the registry, in this example).
This is especially a problem if the computer running MSIE does something
special for .pl files (for example, feed the file to ActiveState Perl).
Here is how to reproduce the bug. Make a simple script like this:
#!/usr/local/bin/perl -w
use strict;
use Apache ();
my $r = Apache-request;
$r-content_type('text/plain');
$r-send_http_header;
$r-print('ok');
Call it plain.reg, and associate .reg files with Apache::Registry. An
.htaccess entry like this may do the trick:
FilesMatch \.reg$
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
/FilesMatch
Now if you access http://www.example.com/plain.reg with MSIE, you may
trigger this bug. (I'm not positive what causes MSIE to ignore
Content-Type on some extensions but not others. If plain.reg doesn't work
for you, try plain.exe, plain.bin, or some other file extensions.)
There are a variety of workarounds.
Easiest is to just fool IE, by making it think the script is named
something else. Most foolproof is to use extra path information:
http://www.example.com/plain.reg/plain.txt
You can also append a dummy parameter. Apparently, MSIE uses a simple
string match to find the extension.
http://www.example.com/plain.reg?bogus=plain.txt
Finally, MSIE respects the Content-Disposition MIME header. This isn't
officially part of the HTTP spec, but is especially useful because you can
suggest a filename. This is nice so that if the user does Save As... or
if your script produces a CSV file or some other application specific
output, a pretty filename will be suggested. Just include a line like this
in the Apache::Registry script before calling send_http_header():
$r-header_out('Content-Disposition' = 'inline; filename=plain.txt');
I just verified all of this on freshly patched IE 6.
Humbly,
Andrew
--
Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED]
Engineer1-800-555-TELL Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
--
Re: Content-Type not working on MSIE
Hello, AGcalled foo.reg, even if it outputs a Content-Type: text/plain webserver, s/webserver,/header,/ Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Content-Type not working on MSIE
Heyas, AHFinally, MSIE respects the Content-Disposition MIME header. This isn't AHofficially part of the HTTP spec, but is especially useful because you AHcan suggest a filename. One more addition. While poking around RFC 2616 for some other stuff I found that Content-Disposition is in fact mentioned in it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1 Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
