HCI Data Ltd
MSIE and text/plain
Home Internet tools
 

CGI Scripts That MSIE Will Not View

A common problem experienced by Microsoft Internet Explorer (MSIE) users is the incorrect display of the document. This is due to MSIE (including MSIE 6.0) ignoring what the information that the web server has sent to describe the document type.

The Content-type Header

When a WWW client (e.g. browser) accesses a remote document using the current HTTP protocols (1.0 or 1.1), then the server is expected to inform the client what kind of content is being returned, by means of the HTTP Content-type header. According to HTTP standards, this information is authoritative. That is, a browser should believe it without question. So, if the Content-type header says the returned document is text/plain, it should be display unformatted in the browser window as a plain text file.

But MSIE makes up its own rules...

The above presentation applies to properly-behaved World Wide Web software - which Win-MSIE, at least all the versions that have been seen so far, up to and including at least version 6.0, are not. For quite a number of important open-defined content types, MSIE does what it thinks best, which - in the case of those who are incompetent to configure a web server - often can seem to be beneficial, but in other practical situations can be utterly frustrating. Worse, it has security implications.

CGI results being downloaded instead of displayed (MSIE)

This again is a fairly common question asked in WWW forums: in spite of the CGI script having supplied an appropriate Content-type header, perhaps text/plain, MSIE decides to download it instead of displaying it according to that content-type. It's another consequence of MSIE's disbelief of server-provided content-types per RFC2616: MSIE has, it seems, fooled itself by trying to make sense of the filename extension on the CGI script. This is most likely when you have the following code in your script:

	
use CGI;

my $query = new CGI;

print $query->header(-type=>'text/plain');
	
 

In this kind of situation, there is a workaround which brings relief in a number of cases, although there's no guarantee of it always working reliably: at least it's better than nothing, unless/until MSIE is fixed to follow the published rules; the technique doesn't use anything that is otherwise invalid or improper.

The technique is to have something after the '.cgi' so that MSIE cannot guess the file type from the URL. Most of the time the URL could be specified to have a query string. This seems to work. If you do not want, or cannot change all the web pages that link to your cgi script, try the following code:

	
use CGI;

my $query = new CGI;

if ($query->param)
{
	print $query->header(-type=>'text/plain');
}
else
{
	print $query->redirect($query->url() . '?a=b');
	exit;
}
	
 

The code has been tested with GET requests, but the redirect will be problematical with POST requests - especially those that upload files! It will add a little extra traffic on the Internet as the browser needs to make to requests to the server. That is (for example):

  1. http://www.hcidata.info/cgi-bin/plain.cgi
  2. http://www.hcidata.info/cgi-bin/plain.cgi?a=b

Now if only I had a penny for every extra HTTP request…




HCI Data Ltd is a member of the Federation of Small Businesses
Last Updated: Saturday, 23-Jan-2016
HCI Data Ltd.