Chapter V. CGI & Client Server Communications

Scripting is what makes Web servers powerful and interactive. Knowledge of HTML tags will only allow you to publish materials--a one way interaction with your users--but scripts, which are actually programs, open up a whole new world of two-way interaction. Before we delve into the script creation process, we must first learn about the Common Gateway Interface--CGI.

The Common Gateway Interface is the communications link between a web browser and the scripts on your computer/web server. All web server software (that I have ever seen) comes with some form of CGI. You can think of this program as an interpreter that converts HTML into a programming language and vice versa. CGIs work with DOS, Windows, Basic, C, C++, Perl, etc.

Now, a quick note about file location on a server. The server software we will work with today is called "httpd" -- hypertext transfer protocol daemon"-- which was created by the folks at NCSA (the same folks who created Mosaic), and is free over the Internet. (A commercial version is also available. ) This particular version of the software is for the Unix platform, although other versions exist for other platforms.

The file structure used with a server generally follows a similar pattern. The main directory is called, naturally, httpd. The HTML files are located in a subdirectory called htdocs, and the CGI is located in a subdirectory called cgi-bin. Scripts are usually in the same subdirectory as the CGI, but can be placed elsewhere in the directory structure for security and/or management reasons.

All the name/value pairs we created on our form pages have a purpose. The pairs are sent by the browser to the server for processing. Let¹s look at the pairs from bkrenuxx.html, which we will examine in the next chapter:

name "Michael Leach"
id "601224430"
email "leach@physics.harvard.edu"
item1 "32044011666789"
item2 "32044011667982"

If we were using the GET attribute of the <FORM> tag, these pairs would be appended (concatenated in computerese!) to the end of the URL as stated in the ACTION attribute. E.G.:

http://www.physics.harvard.edu/cgi-bin/bkrenuxx.pl?name=Michael+Leach
&id=601224430&email=leach%40physics%2eharvard%2eedu

This process, called encoding, is how the http protocol passes the data from browser to server. In http this string is stored (for the GET method) in a environmental variable called Query_String (more on variables shortly). Let¹s look at the encoding steps in more detail.

• -- a question mark (?) follows the URL and precedes the name/value pairs
• -- all data are passed as name/value pairs
• -- the pairs are separated by the ampersand (&)
• -- spaces are converted to the plus sign (+)
• -- special characters are identified by the percent sign and two Hexadecimal digits (%NN)

The first four rules above are straight forward. The last needs more explaining. Certain ASCII characters (such as Tab, (, ), <, >, \, ~, etc.) plus the reserved characters in the rules above (? & + %) are converted to a HEX system, which uses sixteen values -- 0 through 9 and A through F -- to represent the ASCII characters. For instance, the question mark encodes as %3F; the @ as %40; the period as %2e; the & as %26; and the Tab as %09. The full list of rules for encoding are found in RFC1552, which defines MIME (Multimedia Internet Mail Extensions).

You don¹t actually encode the name/value pairs--the browser/server program does. However, it is good for you to know what is going on, and this knowledge will help as we examine Perl scripting later on. Also, the next time you use Dejanews or Alta Vista you can now read the complicated URL which appears in the "Location" portion of the browser screen.

The encoded information is placed in the environmental variable "Query_String" when the method is GET, and into the Perl-defined file handle STDIN when the method is POST.