When setting up your CGI environment, many errors are caused by incorrect access permissions. Make sure
cgi-bin and script permissions are set according to the directions — the same permissions need to apply to any other directory your script wants to write/read from.
Options in .htaccess file
Not all options can be overridden using an .htaccess file. In particular, Drupal installations sometimes include the following line:
If you find this line in your .htaccess file, uncomment it by placing a hash sign in front of it.
# Options +FollowSymLinks
If you see the "
Internal Server Error" or "
script headers" this could be caused by a variety of reasons but usually indicates that your script exited with an error. In cases like this, some error message or nothing at all was output instead of the
Type as the first line of output from the CGI program. Below are some things to try in order to debug the problem:
- Run the script on the command line to make sure it does not generate errors. If written in Perl, run
perl -wcon the file to check syntax. If it is written in PHP, run
php -lon the file to check syntax.
- Try using suexec's debug mode. It is activated by creating a file called .suexecd in the CGI program directory. This causes suexec to print the Content Type before the target CGI program is even run, and also routed all stderr output to stdout, thereby displaying it in the browser. You'll be able to see what would have otherwise gone to the server's error log.
- If your application is written in PHP, you can direct the error messages to a file of your choice using a custom php.ini file. The following would direct all errors and warnings to a file called errors.txt:
error_log = errors.txt
log_errors = On
error_reporting = E_ALL
display_errors = Off
- If this doesn't help, or if the error message is about something server-dependent, contact the CGI administrators by submitting a HelpSU ticket. Note that we will do our best to help you but sometimes your script may be too complex for us to figure out what is wrong.