..and how to fix it.
When running a Perl CGI script, you may see the "Internal Server Error" message in your browser. The message will usually also say something like "please check the server's error-log for more information." You should do that -- the message printed to the error log will often tell you exactly what the problem is. The Apache error log, for example, is often located at /var/log/apache/error_log or /var/log/apache2/error_log (or sometimes "error.log").
If you don't have access to the error log, the next simplest thing to do is to make a copy of the script, then open the original and delete all of its contents, and add just these 3 lines to the file:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "testing...\n";
(Note: if the server is a Windows system, then replace the first line above with either #!perl or #!c:\path\to\perl.exe.)
Now try to access the page in your browser again. If it works (you see "testing..." as its output) then you know that your server is at least configured properly for running Perl CGI scripts. If it doesn't work, then that may mean the problem is in the server configuration, rather than with your CGI script. (For example, are you sure you actually have Perl installed? Virtually all UNIX/Linux/OS X servers do, but Windows servers usually need to have it installed manually, from a package like ActivePerl.)
Assuming your server is configured properly for running CGI scripts, your problem may be one of these common causes for the Internal Server Error:
Problems outside the script:
1. Directory permissions: your cgi-bin directory should be chmodded as 0755, not 0777. Similarly if your script is at .../cgi-bin/foo/bar.cgi, the foo directory must not be world-writable (0777). This is because many servers will refuse to execute CGI scripts within world-writable directories, as a security precaution.
2. File permissions: your CGI script itself must also be 0755 and not 0777, for the same reasons.
3. Transfer modes: if you are using FTP to transfer the CGI script to your server, then your FTP client is probably set to AUTO transfer mode; that is, it will try to figure out whether to use BINARY or ASCII mode without asking you. But depending on whether your CGI script came from a Windows or UNIX system, and whether it's going to a Windows or UNIX system, you may need to manually set your FTP client to use either ASCII or BINARY mode before transferring your CGI script. Try one and then the other.
4. Line endings: the cause of the transfer-mode problem is actually another problem in itself: different types of Operating Systems (namely, Windows vs. UNIX/Linux/everything) use different character codes to represent line-endings. If your server is a UNIX server, but you're editing your CGI script on a Windows computer with a text-editor that doesn't use UNIX-style line-endings, it'll cause problems. Applications like GoLive and Dreamweaver sometimes get this wrong. Even built-in editors can't agree: WordPad (not Word) seems to get it right while Notepad messes it up. So try opening & saving your CGI script in a different text editor and uploading it to the server again.
Problems within the script:
1. The shebang line: the first line of a CGI script must contain the path to the Perl binary on the server. On most UNIX servers this is just #!/usr/bin/perl or sometimes #!/usr/local/bin/perl and you can always run the command "which perl" to find out for sure. On Windows servers, you can sometimes get away with just using #!perl but you may need to specify the full path like #!c:\path\to\perl.exe.
2. Actual script errors: it's always possible that there's simply an error in the Perl code itself. If you're having trouble with a script you purchased from Encodable Industries, this is unlikely since many other people have bought the same exact script and are running it just fine.
Related Problems
1. Another common problem with CGI scripts is the premature end of script headers error.
Reference:
http://encodable.com/internal_server_error/
