Love/Hate Internet Explorer

Many of you are probably aware that the latest versions of Internet Explorer violate W3C specifications and ignore the Content-type: header of documents that are sent. Instead, IE examines the beginning of the document and attempts to infer what the content type should actually be. If you send the header "Content-type: image/gif", but you actually send a jpeg, or a tiff, IE will still render it correctly. That means that pages which render properly on IE may very well fail on other browsers.

Well, I just discovered a new (to me) facet of this problem. I have an administrative console for a Web site that clients know is only used with IE 5.0 or better. No reason to test it on other browsers, right? Wrong.

I recently discovered that the administrative console would not work on IE 5 on a MacOS 8.4. The access logs showed that my programs were getting called properly and returning 200 status codes. No entries were in the error log. Further research revealed that my security routines were still trapping violations behind the scenes. No pages would render, however. Here's the script which failed:

use CGI;
use strict;
use Template;
use Foo::Security;
use Foo::Utilities qw/dienice/;

my $q = CGI->new;
my $template = Template->new( {
    INCLUDE_PATH => '../templates',
    RELATIVE     => 1
} );

my $section       = $q->param( 'section' ) || '';
my $sec           = Foo::Security->new;
my $template_data = { security => $sec->ctl_data };
my $sections      = $sec->get_sections;

if ( ! grep { /$section/ } @$sections ) {
    $sec->send_to_login;
} else {
    $template->process( "${section}-frame.tmpl", $template_data ) or d
+ienice $template->error();
}
[download]

Notice anything funny about it? Anything, anything, Bueller?

Repeat after me: "Ovid is a moron". I never bothered to send a header. IE on Windows realized that the frameset had accidentally been included in the headers and rendered it properly. IE on a Mac didn't catch this and just rendered a blank page. I tested it on Navigator and got the message "Document contains no data." That told me instantly what happened. If IE had bothered to follow standards, I would have caught this bug months ago. Sigh.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Comment on Love/Hate Internet Explorer Download Code

Replies are listed 'Best First'.
Re: Love/Hate Internet Explorer by Masem (Monsignor) on Nov 30, 2001 at 03:44 UTC
This is so much like the recent discussion at Larry vs. Joel vs. Ovid -- in this case, the HTTPD protocol has a well defined format in that the first line sent over the connection is a content type line, and some followup lines that may or may not include details like cookies, content length, etc. But this is all a standard, with only a few small changed (additional fields that could be accepted) since it's release. Yet, Microsoft in their incredible wisdom, is trying too accept too much and refuse little. Your example is one problem; another that I know others have had is that they want to send a HTML document as a text file as an example of code to use; that is, the end file should include all tags and the like. It's possible to force the Content-Text to plain/text on nearly any other browser, but there is absolutely no way to do this in IE; the file will always be rendered as HTML. Now, I'm wondering if there's a reasonable solution that we can at least do with perl and CGI.pm; that is, when you create a new CGI object, there should be a flag that is set when header() is called. If the object is destroyed while this flag is unset, then a warning/die() should be issued that a header was not sent, and there may be erroneous code around (lacking a header line). Obviously, I'd opt to have this as an option that must be set to work, as opposed to a default out of the box. And it's certainly not infallable: this code will not trigger the warning despite header() being called: `my $q = new CGI; $q->header( 'plain/text' ); # It's not being printed!` [download] (Actually, thinkning about it, I'd figure it would be just as easy to create a class such as CGI::HeaderHunter, which acts like a CGI object, but incorporates a "header()" override function and provides a new DESTROY call. Instead of creating a CGI object, you'd create this one. Not quite sure on the details yet, of course...) ----------------------------------------------------- Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain "I can see my house from here!" It's not what you know, but knowing how to find it if you don't know that's important	[reply] [d/l]
(Ovid) Re: Re: Love/Hate Internet Explorer by Ovid (Cardinal) on Nov 30, 2001 at 04:04 UTC
Masem wrote: ...the HTTPD protocol has a well defined format in that the first line sent over the connection is a content type line, and some followup lines that may or may not include details like cookies, content length, etc... That's not quite accurate. The first line of the server's response is typically a status line such as `HTTP/1.1 200 OK`. Subsequent headers may be general headers (e.g. `Date:...`), response headers (e.g. `Location:...`), or entity headers (e.g. `Content-type:...`). These header types may be specified in any order, so long as there is at least one blank line separates the headers and the entity-body. Section 6.1 of RFC2616 specifies that the first line of the response must be the status line. Again, subsequent lines can be sent in an arbitrary order. Interestingly, the protocol makes clear that headers end with two CRLFs ("\r\n"), but most clients issue a "\n\n" instead, but all browsers (that I've run across) interpret this correctly. Is this a case of most Web servers catching and correcting for this, or most browsers being smart enough to handle this? I suspect the former. `Response = Status-Line ; Section 6.1 (( general-header ; Section 4.5 \| response-header ; Section 6.2 \| entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 7.2` [download] Cheers, Ovid Update:* D'oh! Fastolfe is right. I should have said "CGI script" instead of client. Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply] [d/l]
Re: (Ovid) Re: Re: Love/Hate Internet Explorer by Fastolfe (Vicar) on Nov 30, 2001 at 04:29 UTC
Is this a case of most Web servers catching and correcting for this, or most browsers being smart enough to handle this? I suspect the former. And you'd be right. It pays occasionally to remember that `CGI/1.x` != `HTTP/1.x`. The data protocol a CGI script uses to send data to the web server may look like HTTP, but it's CGI. The web server should parse the script's output per the CGI specification, not HTTP, and then issue to the browser a properly-formatted HTTP response. The real question is: Does the CGI specification mandate any specific style of newline? Beats me, but the web server (Apache in my case) seems to like any type of newline I give it. It always generates HTTP newlines as `\cM\cJ`, though.	[reply] [d/l] [select]
Re: Love/Hate Internet Explorer by John M. Dlugosz (Monsignor) on Nov 30, 2001 at 03:28 UTC
Static html can be checked using a strict HTML parser. However, you could check generated code too, for early validation and debugging. Send it off to the validator and write it out to the socket. Or, use a proxy on the client side, which would be a nice general-purpose tool. I agree, I hate IE in how it encourages sloppy and incorrect code.	[reply]
Re: Re: Love/Hate Internet Explorer by ask (Pilgrim) on Dec 01, 2001 at 21:45 UTC
Somewhat related: Apache::ProxyPassThru with Apache::DumpHeaders (or Apache::DumpHeaders alone if you are debugging that server) is a really really useful for figuring out what's going on when things seems to go wrong with that kind of thing. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();	[reply]
Re: Love/Hate Internet Explorer by thraxil (Prior) on Nov 30, 2001 at 21:48 UTC
i wonder how long it will be before some microsoft affiliated site (or new release of IIS) "accidently" stops sending the header and suddenly IE is the only browser that can visit the site. well, i guess it would be more likely that any malevolent intentions that may be behind this are more along the lines of waiting for more and more coders who only test in IE to make the same mistake and after a while netscape users find that more and more sites just mysteriously don't load and give up and move to IE. i'm always curious as to whether microsoft does these things maliciously or just out of their bizarre, insulting philosophy of protecting the user from seeing -- god forbid -- an error message, even when something really is wrong. i can't think of any other reason to so blatantly ignore standards. anders pearson	[reply]


Perl Monk, Perl Meditation
	PerlMonks