Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

---

NOTE:  Programmers sometimes write “generic” code for speed and illustration purposes that is not necessarily correct in any particular language. This code is given a descriptive name: pseudocode. Of course, pseudocode won’t actually compile or interpret; it is meant as a sort of easily understood shorthand, to be converted to actual code in the desired programming language later. Where pseudocode is used in this book, it will be clearly marked.

---

The basic structure of a CGI application is straightforward: initialization, processing, output, and termination. Because this section deals with concepts, flow, and programming discipline, it will use pseudocode rather than a specific language for the examples.

Ideally, a script follows these steps in this order (with appropriate subroutines for do-initialize, do-process, and do-output):

1.  The program begins.

2.  The program calls do-initialize.

3.  The program calls do-process.

4.  The program calls do-output.

5.  The program ends.

Initialization

The first thing your script must do when it starts is determine its input, environment, and state. Basic operating-system environment information can be obtained the usual way: from the system registry in Windows NT, from standard environment variables in UNIX, from .ini files in Windows, and so forth.

State information will come from the input rather than the operating environment or static variables. Remember, each time CGI scripts are invoked, it’s as if they’ve never been invoked before. The scripts don’t stay running between calls. Everything must be initialized from scratch, as follows:

1.  Determine how the script was invoked. Typically, this involves reading the environment variable REQUEST_METHOD and parsing it for the word GET or the word POST.

---

NOTE:  Although GET and POST are the only currently defined operations that apply to CGI, you may encounter other oddball request methods. Your code should check explicitly for GET and POST and refuse anything else. Don’t assume that if the request method isn’t GET then it must be POST, or vice versa.

---

2.  Retrieve the input data. If the method was GET, you must obtain, parse, and decode the QUERYSTRING environment variable. If the method was POST, you must check QUERYSTRING and also parse STDIN. If the CONTENTTYPE environment variable is set to application/x-www-form-urlencoded, the stream from STDIN needs to be decoded, too.

Listing 28.8 shows the initialization phase in pseudocode:

Listing 28.8 Initializing Your CGI Script, Shown in Pseudocode

retrieve any operating system environment values desired
allocate temporary storage for variables
if environment variable REQUESTMETHOD equals “GET” then
   retrieve contents of environment variable QUERYSTRING;
   if QUERYSTRING is not null, parse it and decode it;
else if REQUESTMETHOD equals “POST” then
   retrieve contents of environment variable QUERYSTRING;
   if QUERYSTRING is not null, parse it and decode it;
   retrieve value of environment variable CONTENTLENGTH;
   if CONTENT_LENGTH is greater than zero, read CONTENTLENGTH bytes from STDIN;
   parse STDIN data into separate variables;
   retrieve contents of environment variable CONTENTLENGTH;
   if CONTENTLENGTH equals application/x-www-form-urlencoded
   then decode parsed variables;
else if REQUESTMETHOD is neither “GET” nor “POST then
   report an error;
   deallocate temporary storage;
   terminate
end if

Processing

After initializing its environment by reading and parsing its input, the script is ready to get to work. What happens in this section is much less rigidly defined than during initialization. During initialization, the parameters are known (or can be discovered), and the tasks are more or less the same for every script you’ll write. The processing phase, however, is the heart of your script, and what you do here will depend almost entirely on the script’s objectives.

1.  Process the input data. What you do here will depend on your script. You may ignore all the input and just output the date, for instance, spit back the input in neatly formatted HTML, find information in a database and display it, or do something never thought of before. Processing the data means, generally, transforming it somehow. In classical data processing terminology, this is called the transform step because in batch-oriented processing, the program reads a record, applies some rule to it (transforming it), and then writes it back out. CGI programs rarely, if ever, qualify as classical data processing, but the idea is the same. This is the stage of your program that differentiates it from all other CGI programs, where you take the inputs and make something new from them.

2.  Output the results. In a simple CGI script, the output is usually a header and some HTML. More complex scripts might output graphics, graphics mixed with text, or all the information necessary to call the script again with some additional information. A common and rather elegant technique is to call a script once using GET, which can be done from a standard <A HREF> tag. The script “senses” that it was called with GET and creates an HTML form on-the-fly, complete with hidden variables and code necessary to call the script again, this time with POST. The elegance of this method may be short-lived, however, now that GET is deprecated in the HTML 4.0 specification. This means that although GET is still part of HTML 4.0, it may or may not be included in future versions.