Building a two-way Web

CGI means Common Gateway Interface. A gateway provides data or software access for “outside” computers which may use a different “platform” [operating system and software applications] or different data formats than those behind the gateway. [Hotmail, functioning as a bridge between Web and e-mail, is perhaps the world’s best-known gateway.] In CGI, a process linked to the Web server retrieves or creates data on behalf of visitors to a Web page, who receive tailored content through their ordinary Web browser. [More details and comparison to PHP]

Things behave the same from the user’s point of view regardless of what type of browser is used (kids, don’t try this with JavaScript) because of the Common Interface for presenting data across the boundaries between the various pieces of software. With appropriate “glue” software, the same CGI script can run happily on a variety of Web server platforms as well ... and the details of the code remain hidden from prying eyes (again, unlike JavaScript).

Following are some of the most popular CGI applications (and the data flows happening behind the scenes to make them work).

A classically typical CGI scenario involves using a web-page form to send (submit) a query “upstream” to the Web server, which launches some sort of local executable code that determines the correct reply (perhaps a slice from a private database) and casts it in the form of a Web page. The page is then sent out by the Web server and handled by the browser as any standard HTTP response. This is what’s going on when you do a simple query at a search engine like Google.

CGI-served content may be personalized, by dealing from a small set of predefined variants (perhaps alternate languages, as at Bell.ca) or by building anew “from the ground up”, based on user preferences declared during a previous visit. The preferences can be stored in a cookie left at the user’s computer, and/or in a database at the Web server (in the latter case, a user ID and password are submitted in order to locate the correct record). CGI scripts may also adapt their output according to information the Web browser software sends about itself (for example: can it render HTML frames?) and selections made by the user earlier in the current session.

CGI is also widely used for delivering user feedback to the owner of a Web site. In this case, it’s the upstream data that’s most important (indeed, the thank-you response page may remain constant for all submissions) and the CGI script generally “forks” to an agent such as sendmail that shovels an ordinary e-mail to the site owner without ever revealing his address.

It’s also possible to echo several recent submissions on the response page, in which case we have a guest book (or, if the messages are organized into “threads,” a web board).

The venerable hit counter works by using CGI to insert an image file rather than HTML code. The query data is likely static (“hard-coded”), consisting of codes identifying the specific page and appearance options for the counter. On the server side, the CGI script first locates and increments the appropriate counter (in a plain-text file on disk), then forks to a Graphics Draw progam which magically returns a fully-formed image — those familiar odometer digits — in a format like GIF or BMP, ready for the browser to display.

Serving an image involves sending a raw binary file preceded by plain-text HTTP header information. Webmasters resort to some interesting tricks to fool the server into complying.

The easiest way to add a routine capability like a counter or a guestbook is to find someone who’ll let you share a CGI s/he has running already. Asking the same outfit that’s hosting your pages could get you quickly to an adequate solution (and it gives you leverage on support/uptime issues), but there’s no rule against arranging use of a third-party server if it offers what you need. Either way, just a line or two of HTML (handed to you as part of the deal) gets you rolling, and someone else even pays for the bandwidth  :)

I haven’t ventured to write an in-depth companion to this page (CGI 102?) because several other Web sites already cover the territory so well. Read all those I recommended, if you have time; each one seems to reveal a trick or two the others overlooked.