Date Published: 1999-11-01

There are many reasons why you would receive an "Internal Server Error" when trying to run your cgi/Perl applications.

The information that follows is simply to alert you to the various places where Internal Server Errors can come into play. As always, if you're unsure what are the correct program settings for programs to be run on your web server, contact your server administration -- remember, they're your friends.

Unescaped @ or "

There are several special characters that Perl uses to perform specific functions, such as @ $ " . Internal Server Errors will definitely occur if you have an unescaped @ or " in your variable definition. If you forgot what a variable definition is, you can refer to our article on variables to brush up.

An unescaped $ within a variable definition or subroutine usually will not cause Internal Server Error, but may make your program behave contrary to the way you want it to.

As Perl reads through the script, it will look for these characters and try to execute a command based on it. As you may already know, the @ is used to define arrays (if you didn't know that, you may wish to read our article on arrays), the $ is used to define variables, and the " is used to enclose variable definitions. For this reason, if you want to use any of these symbols within your variable definitions, they'll need to be escaped.

Escaping is simply adding a backslash before the special character. There's a full discussion on character escaping in our Intro to Perl: Variables article.

Not escaping these special characters will cause an error in your program when you try to run it.

The mother of all errors, knowing what permission need to be is paramount for your Perl applications to function.

You’ll need to refer to your program’s documentation to learn what permissions need to be set for which files.

Some Important Notes About Permissions:

1. If your program requires that you change the permissions of the program’s directory to 777 (rwxrwxrwx), make sure that you put the program AWAY from your other cgi programs. Make a new directory, put it outside of the cgi-bin (if you can run cgi programs outside of your cgi-bin), whatever, but do not change the permissions of your cgi-bin. Many times, your server administrator will have to reset them for you if you do.

2. While troubleshooting your scripts, you may be tempted to change the permisions on all files to 777 (rwxrwxrwx), but if you do, remember that this setting offers no security whatsoever. Once your program is complete, remember to change your permissions to whatever is the most secure setting while allowing the program to still function. Also note that some servers will require that permission settings on executable programs are no higher than 775 (rwxrwx-r-x) in order to run.

3. A typical setting for a Perl application is 755 (rwxr-x-r-x); typical setting for a writable data file is 666 (rw-rw-rw-); typical setting for a library is 644 (r-wr-wr-w). These settings vary widely from server to server.
4. If you're trying to write to a file inside of your cgi-bin, you may need to change permissions on the directory to be written to 777. Again, this is contingent on your server. Other servers will not allow you to write to files inside your cgi-bin, meaning you'll have to create (or choose) a directory outside of your cgi-bin for your writeable files.

More information about permissions is found in our August article, entitled What is chmod?.

A very common problem, and is easily fixed. The first line of your program needs to be the correct path to where Perl is installed on your server. A sample path is:

#!usr/bin/perl

If you're not sure where perl is located on your server, you'll need to ask your server administrator. Or, if you have telnet access to your account, you can see where perl is by typing the following at your command prompt:

whereis Perl

Another common problem, and the fix is just to re-upload the file in ASCII format. You'll need to consult your FTP program's documentation to figure out how to switch modes.

BINARY mode is used for non-text items, such as executables (*.exe), zip files (*.zip), image files (*.jpg, *.gif) and the like.

ASCII mode needs to be used for text only documents, which includes *.txt, *.cgi, *.pl, *.css, *.html, etc.

We should hope that if you have purchased or downloaded a cgi/perl program, that this problem won't be an issue. But we wish to be comprehensive, so here it is.

The "content-type" line tells perl that the program is intended yield results to your web browser. If this line is missing where output is supposed to be returned to the browser, this will cause the Internal Server Error.

The correct format to properly print the "content-type" line for an html page is:

print "Content-Type: text/html\n\n";

This line must appear before any text or html code that's to be outputted to your browser.

If you purchased or downloaded a program with a missing "content-type" line, make sure that the program is intended to be run from your web browser instead of the command line.

Again, we hope that if you have purchased or downloaded a cgi/perl program, that this problem won't be an issue. But we wish to be comprehensive, so here it is.

All subroutines begin with a

{

and end with a

}

Most lines must end with a

;

Though there are times when you really don't need the final ; if you're not 100% sure when you don't need it, just toss it in for good measure (except in arrays or hashes). It doesn't hurt when you have it, but it'll hurt when it doesn't when it's supposed to.

The last line of a library (a file that does not actually perform any function, but lists variables or contains only subroutines) must be

1;

This is because each file in the program must return a true value. Placing this 1; on the last line does this.

If you need to use the server path to programs, make sure that it is in a format similar to the following:

/home/yourdomain/pathtoyourprogram

The first slash is necessary. A trailing slash may or may not be required, depending on the program.

Remember, this is just a guideline. If ever you're in doubt, contact your server admin.

If you’re not sure of the exact server path to your file, and you have telnet access, navigate to your file and type:

pwd

You will be given the correct, full path to your file.

If you've installed a program intended to run on an NT server on a Unix server, and it doesn't work -- there's little surprise there. Just as there are Windows and Mac programs, there are NT and Unix cgi/perl programs. You can't run a Mac program on Windows, or visa versa.

Programs designed to run on other operating systems can either function properly, not function properly or not work at all, producing Internal Server Errors. You'll need to make sure that the program you are attempting to run is intended for your web server.

D. Jasmine Merced is a partner in Tintagel Net Solutions Group, Inc. and the administrator of The Perl Archive. She also serves as a Director of the World Organization of Webmasters.