Better Approach Towards CGI Scripts

The first step one should always take in CGI programming is to identify the problem. You might find that many of the tasks you hope to solve using a CGI program have a better alternative solution. For example, suppose you want your home page to have a different image every hour. Using CGI, you could write program that determined the time and displayed the appropriate image. Call the program "time image.cgi". Then, your HTML home page would have the following tag:

Every time someone accesses this page, the server runs time image.cgi. Each time, the CGI program computes the current time, loads the appropriate mage and sends that to stdout. The server parses the CGI headers and redirects the output back to the Web browser. If your Web page is accessed 10,000 times day, time image.cgi goes through the same steps 10,000 times.

Is there a better solution to your problem? In this case, there is. If you have 21 different images, one for each hour of the day, and you want a different image every hour, your HTML file could have the following tag:

Write a program that runs every hour and that copies the appropriate picture to current image.gif. Instead of having a single process running 10,000 times a day, you achieve the same effect running one program 24 times in one day

As another example, suppose you want to make your current Web server statistics available to anyone over the Web. Once again, you could write a CGI program that, when called, would process your server's logs and send the result back to the browser. However, processing server logs can require huge computing resources, especially if your logs are very large. Instead of recomputing the statistics every time someone wants to see them, you are better off computing the statistics periodically, perhaps once a day, and making the results available in an HTML file.

There are often many ways to approach a specific problem, and there is no need to limit yourself to one approach. Before committing to writing a CGI program ask yourself if there is another, better way of solving the problem.

Assuming you have determined that a CGI application is best suited for solving your problem, you should consider the following strategies. First, take advantage of some of the many existing programming libraries that handle most of the repetitive work such as parsing CG I input. Write programs that are general. You might have several very similar programming tasks you need to solve. Instead of writing a separate program for each task, see if you can abstract each problem and find common elements between some of these tasks. If there are common elements, you can probably solve several programming tasks with one, general program. For example, many people commonly use CGI to decode form input and save the results to a file. Writing a program for each separate form seems rather foolish if you are doing the same thing for each form. You should instead write one general form processing program that parses the form and saves it to a user specified file in a user specified format.

Writing general applications is especially advantageous for the Internet service provider. If you are a service provider, you might be reluctant to allow your users to run CGI programs for security reasons. Most users want the ability to parse forms and save or mail the information, a guestbook, and possibly a counter. If you provide general applications that all of your users can use, you might be able to avoid letting anyone else have CGI access. Don't make any false assumptions about your problem. A common mistake in C is to assign statically allocated buffers. For example, suppose you had a form that asked for your age.

If age.cgi is in C, you might assume that because no one has greater than a three digit age and because your form doesn't enable anyone to input an age greater than three digits, you can define age in your program as

char age[3];

However, this is not a safe assumption and the consequences can be severe. The preceding form uses the GET method. There is no way to prevent a user from bypassing your form by using the URL:
http://myserver.org/cgi bin/age.cgi?age=9999

Changing to the POST method doesn't solve the problem. One could still create their own form pointing to http://myserver.org/cgi bin/age.cgi that did not have a maxsize limit on age, or could even directly connect to the Web server and enter the data using HTTP commands.

% telnet myserver.org 80 Trying 127.0.0.1 ... Connected to myserver.org. Escape character is '^]'. POST /cgi bin/age.cgi Content Length: 8 age=9999

The consequences of your false assumption is not just your program crashing. Because it is a network application, malicious users can potentially exploit this weakness in your program to gain unauthorized access to your system. You were probably not aware of this fact if you are not already an experienced network programmer or security expert. Other potential loopholes like this exist as well, of which you are very likely not aware.

Finally, CGI is closely tied to HTML and HTTP. The better you understand both protocols, the more powerful applications you can write. For example, suppose you want to write a CGI program called form.cgi that would display a form if it received no input or would otherwise parse the form. If you know that form.cgi resides in /cgi bin, you would probably print the HTML.

printf.("