The first things you should know about Common Gateway Interface (CGI) are what it is and why it is used. CGI is a standard whose specification defines a way for Web servers to communicate with external programs, and vice versa, so that the external program can generate HTML, images, or whatever, and have the server treat it the same as HTML, images, and so on not generated by an external program. The reason CGI is used is so you can generate dynamic content with the same ease that you generate static content. CGI is used because it is a very well defined and supported standard, and without CGI, dynamic content would have been impossible without proprietary server methods (now, there are alternatives to CGI that are becoming standard).
There are many useful applications of CGI programs. But, as with every other technology, CGI programs have their limits. Also, as with many other technologies, it is not always the best way to do things. For this reason, this chapter will go over what CGI programs can and cannot do, and what CGI based apps are good and bad for.
For comparison's sake, I use Java as the applet language.
As stated earlier, CGI is useful for many different tasks. There are different reasons why it is the best method, or the only method, for a variety of tasks. This chapter examines the reasons, separating the tasks into three different levels. First, we cover simple tasks, which we will define as tasks that can be completed in a couple of hours and/or require almost no knowledge of how to program CGI apps/the CGI spec in general. This task level includes counters, among other things. Next, we cover intermediate tasks, which we will define as tasks that can be completed in a day or two and/or tasks that require a pretty good knowledge of how to program CGI apps/the CGI spec in general. This task level includes built from scratch imagemapping programs, apps that generate entire HTML pages, and apps that do animation, among other things. Finally, we cover advanced tasks, which we will define as tasks that take more than a day or two and/or require an expertise in CGI app programming/the CGI spec in general. This task level includes apps that include a home grown database engine, among other things.
The following is a list of simple tasks in CGI, most of which are covered in this section:
The first level of CGI tasks we will examine are simple tasks. These are tasks that take almost no programming to perform. An example of a simple task would be a hit counter. These are CGI scripts written in either Perl, C, or maybe just a simple shell script, but they all basically work the same way (assuming it's not a very advanced counter). They keep a single data file that stores the number of hits. The program reads that data file and when called, increments the number by one and then returns that number. The code to a counter can be found at ftp://server.berkeley.edu/pub/www/counter, and many other places on the Web. CGI is obviously not the only method for creating counters, but as things stand today, it is the best, for three main reasons.
The first reason that CGI is the best method is simply because it is currently the quickest. The overhead of doing a counter in Java is currently immense because the language is interpreted. Given that there is no advantage to using Java, there is no point.
The second reason is because the CGI standard is the most compatible with today's browsers. Java is not supported by a lot of browsers yet, and the ones that do support it don't do so on all platforms. CGI is a technology that interfaces with HTML. CGI apps generate HTML, or images. Java is a technology that allows you to write real programs and put them on a Web page (assuming you are just writing applets).
The third reason is availability. In my Web travels, when searching for CGI developer resources, I have seen tons of CGI-based counters and CGI code to perform simple tasks, but next to nothing in the way of code for Java. Eventually, this will change due to resources like Gamelan (the official Java applet/application repository, located at http://www.gamelan.com), but since this has not happened yet, it is always easier to use code already written than it is to write your own. This (the prewritten code) is a major factor as to why simple tasks are done in CGI: They are already done by someone else, usually include ample documentation and commented source code, and are waiting for you to just implement on your server.
As we climb up the ladder of difficulty, we reach intermediate CGI tasks, such as the creation of image maps and animation, which are covered in the next section.
The second level of tasks we will examine are intermediate level tasks. This would include things like imagemapping and various other programming tasks that require significant programming work to perform. As you get into intermediate tasks, the line starts to blur on what is easier to do in CGI and what is easier to do in Java.
Some of the tasks that fit into this category are
While basic imagemapping requires no programming when done on the client side, doing something more than just jumping to an HTML page when you click on an image requires programming.
As an example to determine CGI's usefulness for these tasks and its efficiency, we will use a CGI program that handles image zooming. When I click on the image, it zooms in.
There are two ways to do this. You could use CGI and some other program to zoom in, and return a zoomed-in image (written either by yourself or taken from somewhere else), or you could do it in Java, dynamically resizing the image, on the same Web page. So which is better? Well, this is an example of an application where the benefits of programming the application using a CGI library versus programming in Java must be weighed. So let's do that right now, but on a more general scale.
Pros of coding intermediate applications using CGI:
| Note |
Just-In-Time compilers for Java, which speed up apps significantly, are becoming available, so the overhead that comes from the Java code being interpreted will eventually become a nonfactor. |
Cons of coding intermediate applications using CGI:
Pros of coding intermediate applications in Java:
Cons of coding intermediate applications in Java:
Now that you know the pros and cons of coding the application using either Java or a CGI library, which way should you choose? Well, I can't answer that for you. As stated earlier, it varies depending on what kind of application you're talking about, what its purpose is, what the goals are, and so on. On the good side, you do have more than one option for how to do something. Choices are always good to have. They are also good to make, assuming you make the right ones. As we climb to the next rung on the difficulty ladder, we reach advanced-level tasks.
Strangely, unlike intermediate tasks, the advanced tasks are currently a lot easier to perform in CGI than in Java. Examples of such tasks include
The third level of tasks we will examine are advanced tasks. Applications that perform database backending (having an application that accesses a database) are good examples of this.
This is true for a couple of reasons. First, as you have heard many times before, CGI has been around longer and therefore is more defined. This means that I don't have to be the first one to figure out how to index files with a CGI program; it's already been done. This makes the small tasks that combine to form an advanced task, such as database handling, easier. Plus, being older, a lot more major companies have provided ways to handle their particular database format with a CGI program, giving you an easy way to extrapolate the data. Second, Java is a programming language. CGI is a specification for gateway programs. If Java changes significantly, you have to rewrite the entire program. If CGI changes significantly, you just have to upgrade to a new CGI library program.
These are just some of the many advantages of advanced tasks. Because of these advantages, CGI is still useful; however, there are some things CGI is not useful for.
There comes a point where you can do program and app in CGI, or you can code the app using a different language/technology/and so on, and it is easier to code the app with something besides CGI. One example is simple imagemapping. Because an imagemap applet already exists in the JDK (Java Development Kit), you could, with no work, use that to handle imagemapping. It would be a better idea to use both methods at first, but because all major browsers will support Java soon (from Microsoft to Netscape, and many others), it is a better idea to program it in Java. Another example is animation. It is infinitely easier to use the animation applet that the JDK includes to handle animation than it is to use a CGI script; something generated with a CGI script can't appear in the middle of the page and have text after it, unless it uses client push/server pull or some other method. The bottom line is that after Java becomes standard, CGI will mainly be used to write quick and dirty programs and databases (at least until Java Database Connectivity (JDBC) becomes a standard, as well).
CGI programs can do many things on many platforms. In fact, one of the major features implemented in servers supporting CGI specification as opposed to those using other proprietary server extensions is that the programs can be written in any language, and on any platform, as long as they conform to the specification. By comparison, most server extensions are proprietary and specific to one server software, one platform, or both. This means that it's not specifically tied down to the pc, as is VBScript.
Table 1.1 is a comparison of functionality of normal HTML to HTML enhanced with various CGI scripts.
| Task | ||
| Handle forms | ||
| Create almost anything non-static that needs to be on a Web page | ||
| Handle imagemaps | Yes (but only with client side imagemapping) | |
| Add searching to a Web page or set of documents | ||
| Create forms | ||
| Create platform-independent documents | ||
| Create applications such as chat rooms, voting booths, or anything interactive | ||
| Allow pages to be generated on the fly, making it easier to update a group of pages | ||
| Create documents tailored specifically to each user |
Not only can CGI do all these things, but basic CGI applications are extremely easy in C, C++, Shell Scripting, and Perl.
To prove this, here is how to write a "Hello World" CGI application in each of the languages mentioned in the preceding sentence.
The "Hello World"/print all environment variables CGI application in Perl is shown in Listing 1.1.
Listing 1.1. How to print CGI environment variables in Perl.
#!/usr/local/bin/perl
#Just returns an HTML Page with the words "Hello World"
require "cgi-lib.pl"
print &PrintHeader;
print "<TITLE>Hello World</TITLE>"
print "Hello World<P>"
print &PrintEnv;
exit;
In C, with CGI-HTML, the basic app that writes "Hello World" and then prints out the CGI environment looks like Listing 1.2.
Listing 1.2. How to print CGI environment variables in C.
#include <stdio.h>
#include "html-lib.h"
#include "cgi-lib.h"
int main()
{
html_header();
html_begin("Test CGI");
h1("CGI Test Program");
printf("<hr>\n");
h2("CGI Environment Variables");
print_cgi_env();
html_end();
return 0;
}
The same program, written in C++ using the AHTML class library appears in Listing 1.3.
Listing 1.3. How to print CGI environment variables in C++.
#define _DEBUG_DUMP_
#include "a_cgi.hpp"
main ()
{
ACGI acgiOut;
acgiOut.mimeHTML();
acgiOut.cgiEnvironmentDump(0x1); //a_Full dump!
return 0x0;
}
Lastly, the shell script to print out environment variables appears in Listing 1.4.
Listing 1.4. How to print CGI environment variables with a shell script.
#!/bin/sh
echo Content-type: text/plain
echo
echo Hello World
echo SERVER_SOFTWARE = $SERVER_SOFTWARE
echo SERVER_NAME = $SERVER_NAME
echo GATEWAY_INTERFACE = $GATEWAY_INTERFACE
echo SERVER_PROTOCOL = $SERVER_PROTOCOL
echo SERVER_PORT = $SERVER_PORT
echo REQUEST_METHOD = $REQUEST_METHOD
echo HTTP_AccEPT = "$HTTP_AccEPT"
echo PATH_INFO = $PATH_INFO
echo PATH_TRANSLATED = $PATH_TRANSLATED
echo SCRIPT_NAME = $SCRIPT_NAME
echo QUERY_STRING = $QUERY_STRING
echo REMOTE_HOST = $REMOTE_HOST
echo REMOTE_ADDR = $REMOTE_ADDR
echo REMOTE_USER = $REMOTE_USER
echo CONTENT_TYPE = $CONTENT_TYPE
echo CONTENT_LENGTH = $CONTENT_LENGTH
If you look at the apps, you will notice that they are very simple, and all are under 20 lines. This is another good thing about CGI. You can have a lot of functionality without a lot of overhead of handling routine CGI things. But there is a downfall. CGI is limited by the fact that it can't maintain state automatically because HTML is a stateless protocol, and CGI is used to generate HTML (or images embedded in HTML). This means that it cannot be used for certain tasks.
As stated earlier, CGI's usefulness ends on the Web page. After you leave the idea of generated documents that don't change after they are generated (in terms of that specific instance of loading the page), CGI is worthless. Real, live applications embedded on Web pages are the realm of languages such as ActiveScript and Java. These languages will be covered later in the book, specifically in Chapter 28, "ActiveScript," and Chapter 24, "Java and JavaScript as Alternatives to CGI," respectively. Examples of things you can't do in CGI are
As it stands right now, the usefulness of CGI as a standard to program with varies from task to task and difficulty to difficulty. The other major factor is time. CGI is a relatively old technology, and as newer technologies, such as the Java programming language, grow up, they will eventually make it obsolete. But for right now, this has not happened yet, and even when it does, CGI will still have its place.