An instantaneous introduction to CGI scripts and HTML forms

Introduction

To understand this complex interaction, you must first understand how a client and a server work together to deliver a "normal" HTML document. This is the "canonical" Web activity; the "usual" Web function. Then you need to understand how scripts are executed in the Web environment without mediating forms. Once these two processes are clear, you have the foundation to understand the interaction bewteen HTML forms and the scripts that process the data from those forms.

The following diagram shows a WWW client running on a desktop system, Computer A, interacting with two servers: An HTTP server running on Computer B and an HTTP server running on Computer C.

The client running on Computer A gets a document, stored in a file named docu1.html, from the HTTP server running on Computer B. This document contains a link to another document, stored in a file named docu2.html on Computer C. The Uniform Resource Locator (URL) for that link might look something like:

http://ComputerC.domain/docu2.html

If the user activates that link, the client retrieves the file from the HTTP server running on Computer C and displays it on the monitor connected to Computer A.

The HyperText Transfer Protocol defines communication between the client and an HTTP server. The following example shows what an HTTP exchange between a Lynx client and an HTTP server running on Computer C might look like as the client fetches docu2.html.

The client sends the following text to server:

Finally, the client sends a blank line indicating it has completed its request.

The server then responds by sending:

Things to note here:

• Client and server headers are RFC 822 compliant mail headers.
• A Client may send any number of Accept: headers and the server is expected to convert the data into a form the client can accept.

Executing "scripts"

The diagram below shows an hypertext document on Computer B with a link to a file on Computer C that holds the CGI program that will be executed if a user activates the link. This link is a "normal" http: link, but the file is stored in such a way that the HTTP server on Computer C can tell that the file contains a program that is to be run, rather than a document that is to be sent to the client as usual.

When the program runs, it prepares an HTML document on the fly, and sends that document to the client, which displays the document as it would any other HTML document.

Such programs are sometimes called HTTP scripts or "Common Gateway Interface" (CGI) scripts. Note that CGI scripts may be written in scripting languages (like Perl, TCL, etc.) or in any other programming language (like C, Pascal, Basic).

On some HTTP servers these CGI programs are stored in a directory called cgi-bin, and so they are also sometimes called "cgi-bin scripts."

Here is a simple AppleScript program that can be run by a MacHTTP server when it receives a request for the file containing the script. When it runs, this program builds an HTML document containing the current time and returns the document to the WWW client that requested it.

The program is stored in a file named "date", in a folder called "scripts". When a user activates a link that points to this script, the Web client will generate an HTTP request that might look like:

Executing a Script via an HTML Form

A set of tags was added to HTML to direct a WWW client to display a form to be filled out by a user and then forward the collected data to an HTTP server specified in the form.

Servers were modified so that they could then start the CGI program specified in the form and pass the collected data to that program, which could, in turn, prepare a response (possibly by consulting a pre-existing database) and return a WWW document to the user.

The following diagram shows the various components of the process.

<FORM>. . . </FORM>

Define an input form.
Attributes: ACTION, METHOD, ENCTYPE

<INPUT>

Define an input field.
Attributes: NAME, TYPE, VALUE, CHECKED, SIZE, MAXLENGTH

<SELECT> . . . </SELECT>

Define a selection list.
Attributes: NAME, MULTIPLE, SIZE

<OPTION>

Define a selection list selection (within a SELECT).
Attribute: SELECTED

<TEXTAREA> . . . </TEXTAREA>

Define a text input window.
Attribute: NAME, ROWS, COLS

An Example Form

What a Post Query Looks Like

The reply may be HTML, an image file, or any other kind of document, though returning an HTML document is most common.

The script's response to the example query is an HTML document that lists the variable values it received. The HTML looks like:

Possible Input Tag Data Types

TEXT

For entering a single line of text. The SIZE attribute can be used to specify the visible width of the field. The MAX attribute can be used to specify the maximum number of characters that can be typed into the field.

CHECKBOX

For Boolean variables, or for variables which can take multiple values at the same time. When a box is checked, the value specified in its VALUE attribute is assigned to the variable specified in its NAME attribute. If several checkbox fields each specify the same variable NAME, they can be used to assign multiple values to the named variable, since each checkbox field may have a VALUE attribute.

RADIO

For variables which can take only a single value from a set of alternatives. If several radio buttons have the same NAME, selecting one of the buttons will cause any already selected button in the group to be deselected.

SUBMIT

Selecting this link or pressing this button submits the form.

RESET

Selecting this link or pressing this button resets the form's fields to their initial values as specified by their VALUE attributes.

HIDDEN

For passing state information from one form to the next or from one script to the next. An input field of type HIDDEN will not appear on the form, but the value specified in the "VALUE" attribute will be passed along with the other values when the form is submitted.

IMAGE

For displaying an image map within a form and returning the coordinates of a mouse click within the image.

The SELECT Tag

For example, the link to the KU events database is:

Note also that the program that generates the form and the program that processes the form may be the same program. For example, the event query form generated by events-form-get contains the <form> tag:

events-form-get is accessed with a standard HTTP GET method, since any http: URL within an HTML anchor is accessed by using an HTTP GET method, as described earlier.

The server script can unpack the data shipped in the URL somewhat as it can unpack data sent via the POST method.

The ability to append data to an arbitrary URL makes it possible to construct HTML anchors that send data to server scripts when they are activated. This allows document creators to prepare "canned queries" within their documents, something that is not possible with the POST method. For example, the anchor below could generate a list of activites related to athletic events at the University of Kansas when activated if the event script could recognize GET queries with extended URLs (which it does not).