Please Support Our Sponsor Above. Thanks!

---

[Home] [Company] [Hosting] [Scripts] [Support] [Forums]
[Purchase] [Freebies] [Tutorials] [Services] [Advertising]

Last Updated: Thursday, 13-Jul-2000 21:32:30 EDT

This page addresses the more common problems that you may encounter when installing and running CGI scripts. The following message is the standard error message displayed when a problem is encountered while running your CGI scripts. This message doesn't tell you anything about solving the problem that was encountered.

Internal Server Error

This error message does tell you how to find the problem by "asking the administrator to look for messages in the server's error log". However, DON'T waste your time asking the system administrator to look in the server's error log for you. Most system administrators are not responsive to requests for help in debugging your CGI scripts. So it's up to you to find the answers yourself.

Instead, ask your system administrator to assist by answering the question "Where is the server's error log?". If they don't answer this question, you should be finding another service to host your pages.

Once you find the location of your server's error log, you should download and install our error log script which will provide you with more detailed information about the error encountered.

The following list contains the most frequently displayed messages displayed by your server's error log. In many cases, the error message will be vague and won't tell the exact problem. Almost all messages will contain the statement ... "failure: for host XXX.XXX.XXX.XXX trying to GET", so I've only listed the key portion of the message to look for. In all examples below, my use of XXX or xxx denotes variable text and/or numbers.

#!/usr/local/bin/perl

Error: send-cgi reports: can't exec /path/to/script.pl
Cause: Incorrect path to Perl on server. Make sure the first line of your CGI Script starts with #! and points to the path of Perl on your server. Most paths should reflect #!/usr/bin/perl but this is not always the case. To find the path on your server from telnet, type in system command whereis perl

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

Error: cgi-parse-output reports: the CGI program /path/to/script.pl did not produce a valid header (name without value: got line "")
Cause: If the CGI script outputs any results to the browser, such as an HTML formatted page, it must first contain this statement telling the server how the output is to be formatted. This statement must be present prior to any print "xxxxxx"; statements. However, if the script is going to redirect to a different URL after processing, the script will not contain this statement.

print "Use of \"quotes\" Within HTML Tags";

Error: cgi-parse-output reports: the CGI program /path/to/script.pl did not produce a valid header (name without value: got line "bare word found where operator expected at /path/to/script.pl line 8, near "" nextword)
Cause: Improper Use of Quotes. This is one of the most common errors encountered. Because most scripts return an HTML formatted page, the use of quotes in formatting can present unique problems. When using the print ""; to send output to the display, if you use quotes within the command's quoted statement, you must preceed the quote with a backslash ( i.e. /" ). By using a backslash you are telling the compiler to treat the quote as part of the HTML output and not part of the perl process.

You can work around this common problem by replacing the command's first quotation mark from print " to reflect print qq| and ending the command with |; instead of "; as shown below.

print qq|Use of "quotes" Within HTML Tags|;

Instead of using ....

print "Use of \"quotes\" Within HTML Tags";

NOTE: What's nice about this error message is that it will tell you the line number and the next word after the point the error occurred which makes it extremely easy to debug.

require "file.pl";

Error: cgi-parse-output reports: the CGI program /path/to/script.pl did not produce a valid header (name without value: got line "can't locate script.cfg in @inc at /path/to/script.pl line 9.")
Cause: Could not find referenced script in the require statement. Some scripts incorporate other scripts or files in their operation. A good example is the use of wwwboard.cfg configuration file which allows you to make modifications to the wwwboard.cfg without editing the main wwwboard.pl script. This requires the use of the require "wwwboard.cfg"; statement which tells the script to include the wwwboard.cfg file upon execution of the script. If the file referenced in the require statement is in a different directory from the script being executed, you MUST include the full directory path.

This is a common problem when using CRONTAB where a script is executed automatically at a given date/time. If the script being executed contains the require "xxxxx.pl"; statement, be sure to reference the FULL directory path on the server although the script being executed is in the same directory as the required file.

As a general note, always include the FULL directory path of all files referenced in all your scripts. This will eliminate alot of FILE NOT FOUND errors in your scripts and also allows you to move your scripts elsewhere on the site without having to worry about paths referenced in your scripts.

open(FILE, "$filename") || die "Can't open $filename !\n";

Error: cgi-parse-output reports: the CGI program /path/to/script.pl did not produce a valid header (name without value: got line "no such file or directory at /path/to/script.pl line 19.")
Cause: The file referenced in the open() statement could either not be opened as was instructed to abort processing because of the || die "Can't open $response !\n"; statement. The use of the || (double pipe denotes the flow control statement "or") tells the script to OPEN the file OR abort processing. You can leave off the || die "Can't open $response !\n"; portion of the statement in which the script would continue processing. The problem with doing this would be that you wouldn't know that the file was not properly opened.

Using the || die "Can't open $response !\n"; statement will record which file could not be READ or WRITTEN too in your error log. Keep in mind that the portion of the die statement that contains the $variable must match the $variable displayed in the open() statement.

Solution! Check the to make sure the $variable path is correct and that the file permissions to READ and WRITE are properly set accordingly.