Return-Path:
The example shown is from your default httpd.conf
@@ -88,13 +88,13 @@
that everything under that URL prefix will be considered a CGI
program. So, the example above tells Apache that any request for a
resource beginning with /cgi-bin/
should be served from
- the directory /usr/local/apache/cgi-bin/
, and should be
+ the directory /usr/local/apache2/cgi-bin/
, and should be
treated as a CGI program.
For example, if the URL
http://www.example.com/cgi-bin/test.pl
is requested, Apache will attempt to execute the file
- /usr/local/apache/cgi-bin/test.pl
+ /usr/local/apache2/cgi-bin/test.pl
and return the output. Of course, the file will have to
exist, and be executable, and return output in a particular
way, or Apache will return an error message.
cgi-bin
directory, they will need to be able to
run CGI programs elsewhere.
+
+ There are two steps to allowing CGI execution in an arbitrary
+ directory. First, the cgi-script
handler must be
+ activated using the ExecCGI
must be specified in the
A .htaccess
file is a way
- to set configuration directives on a per-directory basis. When Apache
- serves a resource, it looks in the directory from which it is serving
- a file for a file called .htaccess
, and, if it
- finds it, it will apply directives found therein.
+
The .htaccess
tutorial
+ shows how to activate CGI programs if you do not have
+ access to httpd.conf
.
.htaccess
files can be permitted with the
- To allow CGI program execution for any file ending in
+ .cgi
in users' directories, you can use the
+ following configuration.
In the .htaccess
file, you'll need the
- following directive:
If you wish designate a cgi-bin
subdirectory of
+ a user's directory where everything will be treated as a CGI
+ program, you can use the following.
which tells Apache that execution of CGI programs is - permitted in this directory.
Content-Type
set in your CGI program.The exception to this is when the server is configured to - use suexec. This program allows - CGI programs to be run under different - user permissions, depending on which virtual host or user - home directory they are located in. Suexec has very strict - permission checking, and any failure in that checking will - result in your CGI programs failing with an "Internal Server - Error". In this case, you will need to check the suexec log - file to see what specific security check is failing.
When you run a program from your command line, you have certain information that is passed to the shell without you - thinking about it. For example, you have a path, which tells - the shell where it can look for files that you reference.
+ thinking about it. For example, you have aPATH
,
+ which tells the shell where it can look for files that you
+ reference.
- When a program runs through the web server as a CGI - program, it does not have that path. Any programs that you - invoke in your CGI program (like 'sendmail', for example) - will need to be specified by a full path, so that the shell - can find them when it attempts to execute your CGI +
When a program runs through the web server as a CGI program,
+ it may not have the same PATH
. Any programs that you
+ invoke in your CGI program (like sendmail
, for
+ example) will need to be specified by a full path, so that the
+ shell can find them when it attempts to execute your CGI
program.
A common manifestation of this is the path to the script @@ -329,17 +339,40 @@
Make sure that this is in fact the path to the interpreter.
+ +In addition, if your CGI program depends on other environment variables, you will need to + assure that those variables are passed by Apache.
+Most of the time when a CGI program fails, it's because of a problem with the program itself. This is particularly true once you get the hang of this CGI stuff, and no longer make - the above two mistakes. Always attempt to run your program - from the command line before you test if via a browser. This - will eliminate most of your problems.
+ the above two mistakes. The first thing to do is to make + sure that your program runs from the command line before + testing it via the web server. For example, try: + +(Do not call the perl
interpreter. The shell
+ and Apache should find the interpreter using the path information on the first line of
+ the script.)
The first thing you see written by your program should be
+ a set of HTTP headers, including the Content-Type
,
+ followed by a blank line. If you see anything else, Apache will
+ return the Premature end of script headers
error if
+ you try to run it through the server. See Writing a CGI program above for more
+ details.
The suexec support program
+ allows CGI programs to be run under different user permissions,
+ depending on which virtual host or user home directory they are
+ located in. Suexec has very strict permission checking, and any
+ failure in that checking will result in your CGI programs
+ failing with Premature end of script headers
.
To check if you are using suexec, run apachectl
+ -V
and check for the location of SUEXEC_BIN
.
+ If Apache finds an suexec binary there on startup, suexec will
+ be activated.
Unless you fully understand suexec, you should not be using it.
+ To disable suexec, simply remove (or rename) the suexec
+ binary pointed to by SUEXEC_BIN
and then restart the
+ server. If, after reading about suexec,
+ you still wish to use it, then run suexec -V
to find
+ the location of the suexec log file, and use that log file to
+ find what policy you are violating.
- ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/
+ ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
The example shown is from your default httpd.conf
@@ -84,13 +84,13 @@
that everything under that URL prefix will be considered a CGI
program. So, the example above tells Apache that any request for a
resource beginning with /cgi-bin/
should be served from
- the directory /usr/local/apache/cgi-bin/
, and should be
+ the directory /usr/local/apache2/cgi-bin/
, and should be
treated as a CGI program.
For example, if the URL
http://www.example.com/cgi-bin/test.pl
is requested, Apache will attempt to execute the file
- /usr/local/apache/cgi-bin/test.pl
+ /usr/local/apache2/cgi-bin/test.pl
and return the output. Of course, the file will have to
exist, and be executable, and return output in a particular
way, or Apache will return an error message.
cgi-bin
directory, they will need to be able to
run CGI programs elsewhere.
+ There are two steps to allowing CGI execution in an arbitrary
+ directory. First, the cgi-script
handler must be
+ activated using the AddHandler
or SetHandler
directive. Second,
+ ExecCGI
must be specified in the Options
directive.
- <Directory /usr/local/apache/htdocs/somedir>
+ <Directory /usr/local/apache2/htdocs/somedir>
Options +ExecCGI
@@ -133,40 +138,48 @@
programs:
- AddHandler cgi-script cgi pl
+ AddHandler cgi-script .cgi .pl
A .htaccess
file is a way
- to set configuration directives on a per-directory basis. When Apache
- serves a resource, it looks in the directory from which it is serving
- a file for a file called .htaccess
, and, if it
- finds it, it will apply directives found therein.
+
The .htaccess
tutorial
+ shows how to activate CGI programs if you do not have
+ access to httpd.conf
.
.htaccess
files can be permitted with the
- AllowOverride
directive,
- which specifies what types of directives can
- appear in these files, or if they are not allowed at all. To
- permit the directive we will need for this purpose, the
- following configuration will be needed in your main server
- configuration:
+
+ To allow CGI program execution for any file ending in
+ .cgi
in users' directories, you can use the
+ following configuration.
- AllowOverride Options
+ <Directory /home/*/public_html>
+
+ Options +ExecCGI
+ AddHandler cgi-script .cgi
+
+ </Directory>
In the .htaccess
file, you'll need the
- following directive:
If you wish designate a cgi-bin
subdirectory of
+ a user's directory where everything will be treated as a CGI
+ program, you can use the following.
- Options +ExecCGI
+ <Directory /home/*/public_html/cgi-bin>
+
+ Options ExecCGI
+ SetHandler cgi-script
+
+ </Directory>
which tells Apache that execution of CGI programs is - permitted in this directory.
+Content-Type
set in your CGI program.The exception to this is when the server is configured to - use suexec. This program allows - CGI programs to be run under different - user permissions, depending on which virtual host or user - home directory they are located in. Suexec has very strict - permission checking, and any failure in that checking will - result in your CGI programs failing with an "Internal Server - Error". In this case, you will need to check the suexec log - file to see what specific security check is failing.
-When you run a program from your command line, you have certain information that is passed to the shell without you - thinking about it. For example, you have a path, which tells - the shell where it can look for files that you reference.
+ thinking about it. For example, you have aPATH
,
+ which tells the shell where it can look for files that you
+ reference.
- When a program runs through the web server as a CGI - program, it does not have that path. Any programs that you - invoke in your CGI program (like 'sendmail', for example) - will need to be specified by a full path, so that the shell - can find them when it attempts to execute your CGI +
When a program runs through the web server as a CGI program,
+ it may not have the same PATH
. Any programs that you
+ invoke in your CGI program (like sendmail
, for
+ example) will need to be specified by a full path, so that the
+ shell can find them when it attempts to execute your CGI
program.
A common manifestation of this is the path to the script @@ -323,16 +330,36 @@
Make sure that this is in fact the path to the interpreter.
+In addition, if your CGI program depends on other environment variables, you will need to + assure that those variables are passed by Apache.
-Most of the time when a CGI program fails, it's because of a problem with the program itself. This is particularly true once you get the hang of this CGI stuff, and no longer make - the above two mistakes. Always attempt to run your program - from the command line before you test if via a browser. This - will eliminate most of your problems.
+ the above two mistakes. The first thing to do is to make + sure that your program runs from the command line before + testing it via the web server. For example, try: + +
+ cd /usr/local/apache2/cgi-bin
+ ./first.pl
+
(Do not call the perl
interpreter. The shell
+ and Apache should find the interpreter using the path information on the first line of
+ the script.)
The first thing you see written by your program should be
+ a set of HTTP headers, including the Content-Type
,
+ followed by a blank line. If you see anything else, Apache will
+ return the Premature end of script headers
error if
+ you try to run it through the server. See Writing a CGI program above for more
+ details.
The suexec support program
+ allows CGI programs to be run under different user permissions,
+ depending on which virtual host or user home directory they are
+ located in. Suexec has very strict permission checking, and any
+ failure in that checking will result in your CGI programs
+ failing with Premature end of script headers
.
To check if you are using suexec, run apachectl
+ -V
and check for the location of SUEXEC_BIN
.
+ If Apache finds an suexec binary there on startup, suexec will
+ be activated.
Unless you fully understand suexec, you should not be using it.
+ To disable suexec, simply remove (or rename) the suexec
+ binary pointed to by SUEXEC_BIN
and then restart the
+ server. If, after reading about suexec,
+ you still wish to use it, then run suexec -V
to find
+ the location of the suexec log file, and use that log file to
+ find what policy you are violating.