Introduction
The CGI (Common Gateway
Interface) defines a way for a web server to interact with external
content-generating programs, which are often referred to as CGI programs or CGI
scripts. It is the simplest, and most common, way to put dynamic content on
your web site. This document will be an introduction to setting up CGI on your
Apache web server, and getting started writing CGI programs.
Configuring
Apache to permit CGI
In order to get your CGI programs
to work properly, you'll need to have Apache configured to permit CGI
execution. There are several ways to do this.
ScriptAlias
The ScriptAlias directive tells
Apache that a particular directory is set aside for CGI programs. Apache will
assume that every file in this directory is a CGI program, and will attempt to
execute it, when that particular resource is requested by a client.
The ScriptAlias
directive looks like:
ScriptAlias
/cgi-bin/ /var/www/cgi-bin/
The example shown is from your
default httpd.conf configuration file, if you installed Apache in the default
location. The ScriptAlias directive is much like the Alias directive, which
defines a URL prefix that is too mapped to a particular directory. Alias and
ScriptAlias are usually used for directories that are outside of the
DocumentRoot directory. The difference between Alias and ScriptAlias is that
ScriptAlias has the added meaning 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 ‘/var/www/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 ‘/var/www/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 outside of
ScriptAlias directories
CGI programs are often restricted
to ScriptAlias'ed directories for security reasons. In this way, administrators
can tightly control who is allowed to use CGI programs. However, if the proper
security precautions are taken, there is no reason why CGI programs cannot be
run from arbitrary directories. For example, you may wish to let users have web
content in their home directories with the UserDir directive. If they want to
have their own CGI programs, but don't have access to the main 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.
Explicitly
using Options to permit CGI execution
You could explicitly use the
Options directive, inside your main server configuration file, to specify that
CGI execution was permitted in a particular directory:
<Directory
/var/www/cgi-bin/>
Options
+ExecCGI
</Directory>
The
above directive tells Apache to permit the execution of CGI files. You will
also need to tell the server what files are CGI files. The following AddHandler
directive tells the server to treat all files with the cgi or pl extension as CGI
programs:
AddHandler
cgi-script .cgi .pl
User
Directories
To
allow CGI program execution for any file ending in .cgi in users' directories,
you can use the following configuration.
<Directory
/var/www/cgi-bin/>
Options
ExecCGI
AddHandler
test .pl .cgi
AllowOverride
None
Order
allow,deny
Allow
from all
</Directory>
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.
<Directory
/home/*/public_html/cgi-bin>
Options
ExecCGI
SetHandler
test .pl cgi-script
AllowOverride
None
Order
allow,deny
Allow
from all
</Directory>
Writing a CGI
program
There are two main differences between
“regular” programming, and
CGI programming.
First, all output from your CGI
program must be preceded by a MIME-type header. This is HTTP header that tells
the client what sort of content it is receiving. Most of the time, this will
look like:
Content-type: text/html
Secondly, your output needs to be
in HTML, or some other format that a browser will be able to display. Most of
the time, this will be HTML, but occasionally you might write a CGI program
that outputs a gif image, or other non-HTML content.
Apart from those two things,
writing a CGI program will look a lot like any other program that you might
write.
Your first CGI
program
The
following is an example CGI program that prints one line to your browser. Type
in the following, save it to a file called first.pl, and put it in your cgi-bin
directory.
[root@server1
~]# vim /var/www/cgi-bin/first.pl
#!/usr/bin/perl
print
"Content-type: text/html \n\n";
print "Hello,
World..!!";
:wq
Even if you are not familiar with
Perl, you should be able to see what is happening here. The first line tells
Apache (or whatever shell you happen to be running under) that this program can
be executed by feeding the file to the interpreter found at the location
/usr/bin/perl. The second line prints the content-type declaration we talked
about, followed by two carriage-return newline pairs. This puts a blank line
after the header, to indicate the end of the HTTP headers, and the beginning of
the body. The third line prints the string "Hello, World.". And
that's the end of it.
If
you open your favorite browser and tell it to get the address.
http://www.example.com/cgi-bin/first.pl
or wherever you put your file,
you will see the one line Hello, World. Appear in your browser window. It's not
very exciting, but once you get that working, you'll have a good chance of
getting just about anything working.
But it's still not working!
There
are four basic things that you may see in your browser when you try to access
your CGI program from the web:
The output of your CGI program
Great! That means everything worked fine.
If the output is correct, but the browser is not processing it correctly, make
sure you have the correct Content-Type set in your CGI program.
The
source code of your CGI program or a "POST Method Not Allowed" message
That means that you have not properly
configured Apache to process your CGI program. Reread the section on
configuring Apache and try to find what you missed.
A
message starting with "Forbidden"
That means that there is a permissions
problem. Check the Apache error log and the section below on file permissions.
A
message saying "Internal Server Error"
If you check the Apache error log, you will
probably find that it says "Premature end of script headers", possibly along
with an error message generated by your CGI program. In this case, you will
want to check each of the below sections to see what might be preventing your
CGI program from emitting the proper HTTP headers.
File
permissions
Remember
that the server does not run as you. That is, when the server starts up, it is
running with the permissions of an unprivileged user - usually nobody, or www -
and so it will need extra permissions to execute files that are owned by you.
Usually, the way to give a file sufficient permissions to be executed by nobody
is to give everyone execute permission on the file:
[root@server1
~]# chmod a+x /var/www/cgi-bin/first.pl
Also,
if your program reads from, or writes to, any other files, those files will
need to have the correct permissions to permit this.
Path
information and environment
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.
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 interpreter (often perl) indicated in the first line of
your CGI program, which will look something like:
#!/usr/bin/perl
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.
Program errors
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. 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:
[root@server1 ~]# cd /var/www/cgi-bin/
[root@server1 ~]# ./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.
Open your favorite browser and tell it to get the address.
http://www.example.com/cgi-bin/first.pl
No comments:
Post a Comment