What CGI Is

CGI stands for the Common Gateway Interface. It is a rulebook that tells a client how to communicate information in an HTML form back to a server, and tells the server how to form its response to the client.

What CGI Isn’t

CGI is not a program. CGI is not a programming language. When we refer casually to a “CGI program,” we mean “a program, written in some programming language, that follows the rules of CGI.”

The CGI Process

Sending Form Information

When you click the Send button on a form on an HTML page, the client does the following:

1. For each field on your form, the client creates a string of the form fieldname=value.
2. The field name and value are URL-encoded; that is, any character that wouldn’t be valid in a URL is encoded in a form that makes it acceptable.
3. These fields and values are connected by ampersands.
4. The resulting string is sent to the server, along with the URL that you requested

At the Server

Once the request gets to the server, your CGI program is activated. It can then look at the field-names-and-values string, take it apart, URL-decode the values, and then use them in processing the data. Your server also sets up environment variables as described on pages 384-388, and your program has access to them as well when it wakes up.

Forming the Response

In order to discuss this topic, we first need to see what happens when you send a request for a static HTML page. The server grabs that file and then attaches an HTTP header to the document. This header specifies what kind of content it is sending back to the client. If it’s an HTML file, the header has this:

Content-type: text/html

If it’s a plain text file, the header is Content-type: text/plain. A graphic file might have this in the header: Content-type: image/jpg.

The header can have a lot of other information in it, but the most important part of the header is the Content-type. The header is followed by a blank line, and then by the actual data that is to be sent to the client. You have never seen this header before, because the client doesn’t need to show it to you. It just uses the information to determine how to display the information. Think of the HTTP header as a little yellow sticky that the server puts on the document. The client peels off the sticky before it displays the data on your screen.

All of this HTTP header business is taken care of by the server software that provides static HTML pages. You never need to worry about it, and in fact, most of you are probably totally unaware of its existence. However, when you are writing a CGI script, there is no static page, and your script must provide the HTTP header.

cgi.pm

All of the code on the server side that is associated with splitting apart the form field values and URL-decoding them and creating an HTTP response header is code that is virtually the same in every CGI script. Rather than reinventing the wheel, we use a vey powerful Perl module named cgi.pm which does most of this work for us. All of the work of analyzing and decoding the field names is accomplished with:

use CGI;
my $cgi = new CGI;

Accessing the value of a field is as simple as $value = $cgi->param($fieldname); or, for fields that can have multiple values, @value = $cgi->param($fieldname);.

Creation of the HTTP header is accomplished with $cgi->header();. The cgi.pm module has a huge number of subroutines that help you generate HTML, but as far as I am concerned, they are much more trouble than they are worth. Generating the HTML directly with print statements is usually far more readable and maintainable.