Recently one of my clients was having some issues with a CGI script they purchased. They’re running IIS on all of their servers, and oddly, this purchased script worked on one of their servers but not the other. On the server where the script wasn’t running correctly, IE displayed “Content-type: text/html” at the top of the CGI page. If I remember correctly FireFox displayed the entire markup of the page in text.
After quite a bit of research I found this excellent Perl for Win32 FAQ and learned that when you setup Perl for IIS you have two options, you can use “Perl for Win32” or you can use “PerlIS.” In my client’s case, they were running Perl for Win32 on the server with the working script and PerlIS on the server with the broken script.
Perl for Win32 = perl.exe
PerlIS = perlis.dll
They are both the same version of Perl, and both come included when you download Perl for Windows. However, even though they are the same version of Perl, they are different “interpreters.”
Perl for Win32 and PerlIS are mostly alike, but PerlIS requires that your scripts include the HTTP response status line as well as all headers for the response. Using Perl for Win32 you only need to specify the headers.
PerlIS is about two times faster than Perl for Win32. However, most CGI script that you purchase, or download for free, do not specify the HTTP response status line. This is because most scripts are not written for PerlIS. (Ok, I can’t backup that claim, but that seems to be the case in my experience.)
If your Perl scripts are displaying the content-type at the top of the page, try configuring your IIS server to run Perl using perl.exe instead of perlis.dll.
One thought on “Why is "Content-type: text/html" displayed at the top of my CGI pages?”
Or search in the script for “Content-type” and add “HTTP/1.0 200 OK\n” just before the Content-type.
Also PerlIs is not two times faster. The execution of the script is just as quick in both, the engine that runs the script is the same. The difference is that with perl.exe the webserver has to create a new process for each and every request. It doesn’t for PerlIs. PerlIs runs inside the IIS process (or the AppPool) and no new processes are created.
So the smaller the scripts, the bigger the difference. In both speed and memory footprint.