Perl for Win32 Frequently Asked Questions (FAQ)

6. Web Server Configuration and Troubleshooting

6.1. What HTTP servers support the Perl for Win32 interpreter?

Most Windows NT and Windows 95 servers that use the CGI standard or ISAPI will run Perl for Win32 scripts. The following servers are known to work with Perl for Win32 (known protocols in brackets):

Microsoft Internet Information Server and Peer Web Services [CGI, ISAPI] (http://www.microsoft.com/iis/)
EMWAC Web Server [CGI] (http://emwac.ed.ac.uk/html/internet_toolchest/https/contents.htm)
Alibaba from Computer Software Manufaktur [CGI, ISAPI] (http://alibaba.austria.eu.net/)
Netscape Communications Server, Enterprise Server, and FastTrack Server [CGI] (http://home.netscape.com/)
Fnord for Windows 95 [CGI] (http://www.wpi.edu/~bmorin/fnord/) [Note: you must be able to see the fnords to read this Web page. -ESP]
Purveyor by Process Software [CGI, ISAPI] (http://www.process.com/)
O'Reilly Website Professional [CGI, ISAPI] (http://software.ora.com/)

[Any others? -ESP]

There's a list of Web servers for Windows, Windows 95, and Windows NT on this Yahoo Page:

http://www.yahoo.com/Computers_and_Internet/Software/Internet/ World_Wide_Web/Servers/Microsoft_Windows_Windows_95/

(That's all one URL.)

6.2. How do I configure the EMWAC https server to support Perl for Win32?

First, read the EMWAC documentation for this is at

http://emwac.ed.ac.uk/html/internet_toolchest/https/scripts.htm

Briefly, you need to follow these steps:

Install Perl for Win32.
Install the EMWAC server. Ensure that you can read HTML files correctly from the server.
Make sure that the bin subdirectory of your perl directory is in the system PATH variable. Note that this must be set in the Control Panel, not on the command line, and it must be a system environment variable, not a user environment variable.
Make sure that your script has the extension .pl. This is the only way that the https service recognizes the file as a Perl script.
Ensure that the script is readable by the account used by the EMWAC server. Generally, this means you should make the script readable by the Everyone group.
Ensure that all supporting files, like the perl binary files, the perl library files, and the modules that you use, are all readable by the account used by the EMWAC server (i.e., the Everyone group).

When the EMWAC server gets an HTTP request for a file with a .pl extension, it tries to execute "perl [filename]". This is the only way you can get Perl scripts to work on the EMWAC server, so you need to follow the above directions to get this to work.

By default, Perl for Win32 install.bat puts perl.exe in the system path, but it doesn't hurt to double-check.

Because the EMWAC server runs as a service (see question 4.8), you need to take special steps to make files and environment variables like PATH accessible. Just because you can read a script and run it from the command line doesn't mean that the server can.

[Anything else? -ESP]

6.3. How do I configure Microsoft Internet Information Server to support Perl for Win32?

Microsoft Internet Information Server (IIS) ships with Windows NT Server. Peer Web Services (PWS) ships with Windows NT Workstation. Configuring the products is essentially the same. First, you should consult Chapter 8, Publishing Information and Applications, in the IIS documentation.

Also read the Microsoft Knowledge Base article covering this issue, "Configuring and Testing a PERL [sic] Script with IIS," (http://www.microsoft.com/kb/articles/q150/6/29.htm).

You need to follow these steps to get Perl for Win32 scripts to run under IIS:

Associate the extension for your scripts with the appropriate interpreter in the script map for IIS. This is under the registry key HKEY_LOCAL_SYSTEM, with the sub-key "System\CurrentControlSet\Services\W3SVC\Parameters\Script Map". Many people map two extensions: one to perl.exe (like ".pl") and another to PerlIS.dll (like ".plx"). Note that mapping an extension in the script map is _not_ the same as associating the extension in Explorer. Use the full paths to the executable files in the script map.
Put your scripts in a virtual directory on the server that has Execute access but not Read access. You can add virtual directories or view their access with the Internet Service Manager. Remember that the URLs for your virtual directories can't overlap with URLs to directories in the WWW root directory. For example, You can't have a cgi-bin virtual directory and a real cgi-bin subdirectory of the WWW root.
Ensure that your scripts are readable by the account used by the IIS server. You set this account in Internet Service Manager; it is set to IUSR_[your server name] by default. See question 4.9.
Ensure that all supporting files, like the perl binary files, the perl library files, and the modules that you use, are all readable by the account used by the IIS server. See question 4.9.

By default, Perl for Win32 install.bat maps the .pl extension to PerlIS. You can override the extension used during installation. Because install.bat does this for you when IIS is already installed, it can be easier to install IIS first, then install Perl for Win32.

You need to restart the Web service after making the registry changes.

Because IIS runs as a service (see question 4.8), you need to take special steps to make sure that files and environment variables are available to it.

6.4. How do I configure Netscape Web servers to support Perl for Win32?

If you're using Netscape 1.x servers, you must wrap your Perl scripts in batch files. Refer to these Netscape tech notes:

http://help.netscape.com/kb/server/960513-3.html http://help.netscape.com/kb/server/960513-125.html

The following information is for Netscape FastTrack Server 2.0. Other 2.0 Netscape Servers (Communications, Enterprise) should be similar [? -ESP].

First, read the Netscape documentation. Next, read the technote on Shell CGI (http://help.netscape.com/kb/server/960804-35.html).

In order to set up Perl for Win32 to run on FastTrack Server,

Install FastTrack Server, and make sure you can retrieve HTML pages.
Set up a "Shell CGI Directory" to run Perl scripts. A regular CGI Directory will not work -- that is only for executable files. You set this up with the FastTrack Administrator; see the documentation for details. You will only be able to access Perl CGI scripts that are in this directory.
Associate Perl scripts with the perl interpreter, if you haven't already. See question 4.10 for how to do this. You may need to re-start the server after making the association.
Ensure that the script is readable by the account used by the Netscape service. Generally, this means you should make the script readable by the Everyone group.
Ensure that all supporting files, like the perl binary files, the perl library files, and the modules that you use, are all readable by the account used by the Netscape service (i.e., the Everyone group).

One nice thing about FastTrack server is that the Error Log will give detailed reasons why your CGI script isn't running, so this is a good thing to check first when you are having configuration problems.

Because Netscape servers run as services (see question 4.8), you need to take special steps to make sure that files and environment variables are available to them.

Many people have reported problems with handling POST'ed data with Perl programs with Netscape servers. Since Netscape apparently uses associations to run scripts, and POST'ed data is send on STDIN to a program, this may be related to the problems with redirection mentioned in question 4.3.

6.5. How do I configure WebSite to support Perl for Win32?

The following information is for setting up O'Reilly WebSite to use Perl for Win32 for standard CGI (not PerlIS). Other O'Reilly servers (WebSite Professional) should be similar [? -ESP].

Install WebSite. Make sure you can retrieve HTML pages before continuing.

Associate Perl scripts with the perl interpreter, if you haven't already. See question 4.10 for how to do this. You may need to re-start the server after making the association.
Set up a "Standard CGI Directory" to hold your Perl scripts. You can use the Server Properties dialog box do to this.
Ensure that the script is readable by the account used by the WebSite service. Generally, this means you should make the script readable by the Everyone group.
Ensure that all supporting files, like the perl binary files, the perl library files, and the modules that you use, are all readable by the account used by the WebSite service (i.e., the Everyone group).

Because WebSite servers run as services (see question 4.8), you need to take special steps to make sure that files and environment variables are available to them.

6.6. How do I configure Purveyor to support Perl for Win32?

The following instructions are for Purveyor 1.2 for Windows NT. Other Purveyor products should be similar.

In the Purveyor Control Panel, use the CGI Mapping tab to map the .pl extension to perl.exe. Make sure that you use the full path to the executable.
Also in the Purveyor Control Panel, use the Virtual Servers section to set your CGI Scripts Directory. You need one scripts directory for each virtual server you support. The scripts directory must be in the data path for the server. Also, make sure that the Disable CGI Extension checkbox is unchecked.
Ensure that the script is readable by the account used by the Purveyor service. Generally, this means you should make the script readable by the Everyone group.
Ensure that all supporting files, like the perl binary files, the perl library files, and the modules that you use, are all readable by the account used by the Purveyor service (i.e., the Everyone group).

If you have problems while configuring Purveyor to use Perl for Win32, you can use the Enable Tracing checkbox in the Logging tab of the Purveyor Control Panel applet to trace HTTP requests and responses.

Because Purveyor runs as a service (see question 4.8), you need to take special steps to make sure that files and environment variables are available to it.

6.7. How do I configure Microsoft Personal Web Server for Windows 95 to support Perl for Win32?

Microsoft Personal Web Server for Windows 95 is a scaled-down version of Microsoft Internet Information Server. Although it is not documented, it appears that the method used to support Perl for Win32 with IIS will also work with Personal Web Server. See question 6.3.

6.8. How do I configure Web Server X to support Perl for Win32?

If your Web server isn't listed, check the server's documentation on how to set up a CGI interpreter. In general the process is as follows:

Associate a file extension like .pl with the perl binary, and let the server know where the binary is. This may be a shell association, as described in question 4.10, or a custom association.
Setup a directory where executable scripts go, and put your Perl script there.
Ensure that the user account that the Web server uses can read the script as well as any ancillary files (perl binary files, library files, modules, etc.). This usually means making the files available to the Everyone group.

Because most Web servers run as services (see question 4.8), you need to take special steps to make sure that files and environment variables are available to them.

[If you get a Web server not listed here working with Perl for Win32, please send me a message and I'll include it in the FAQ. -ESP]

6.9. My program runs fine from the command line, but bombs out when run as a CGI script. Why?

Usually, this means one of two things: either you have misconfigured your system, or your script does not output the right stuff to be a CGI script.

You have specified the path to perl.exe correctly in your extension map, however that map is made
If you depend on the PATH variable, make sure that you put perl.exe in your system PATH, not just your personal PATH
The directory you use has Execute access, however that is specified with your Web server
The server's user account has Read permissions to the script file
The server's user account has Read permissions to the perl tools (binaries, library, modules)

[Anything else? -ESP]

Check the information above with a script that you _know_ creates the right output for the CGI protocol (scripts in this FAQ are a good first choice). Try it with your own script after you're sure the test script will work.

Whatever you do, don't give up hope. It is, in fact, possible to get a Perl script running on your Web server. Really.

6.10. This is all such a hassle; why can't I just put perl.exe in my CGI directory and use it in my URL?

First, the warning: DON'T DO THIS. REALLY. EVEN IF YOU DON'T UNDERSTAND WHY NOT, DON'T.

Now the explanation: the idea here is to put perl.exe in your CGI directory (however you configure that on your server), and use URL syntax like the following:

http://soon.to.be.a.victim.net/cgi-bin/perl.exe?myscript.pl

to run myscript.pl. This keeps you from having to figure out how to configure your server to associate extensions like .pl with an interpreter like perl.exe.

In fact, on some early Win32-based Web servers (Netscape 1.x servers in particular), it was impossible to associate a script file with an interpreter. This method was recommended by vendors as a viable approach to running Perl scripts on your Web server.

Anyone with a devious mind and a little knowledge of perl can see that with this configuration, hackers could start doing all kinds of horrible things on the server. All they'd have to do is send made-up URLS, using the -e command line switch in perl.exe, in order to do stuff like delete all files on a drive:

http://aaaugh.that.hurts.net/cgi-bin/perl.exe?-e?'del%20c:\*.*%20/S%20/Q'

Of course, a true computer criminal would never do something so crude and obvious, but would instead use this as a launching point to cause irreparable harm to your organization.

The following URL covers this issue in more depth:

ftp://cert.org/pub/cert_advisories/CA-96.11.interpreters_in_cgi_bin_dir

Tom Christiansen has also written a good discussion of the subject, tainted with the kind of UNIX bigotedness that is sure to make the blood of PC professionals boil:

http://www.perl.com/perl/news/latro-announce.html

Note that one suggested solution to this problem is wrapping your Perl script in a batch file using PL2BAT or your own custom batch code. THIS IS ALSO NOT GOOD. Most of the primitive servers that won't allow file associations are also susceptible to a bug that allows a user to enter any DOS command after the bat file.

For more information on CGI and Web server security, see these URLs:

Web: http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html CGI: http://www.cerf.net/~paulp/cgi-security/safe-cgi.txt

As a final note, there are so many good, free Web servers out there for Windows NT and Windows 95 that you should never stay with an old, insecure Web server.