Section B.16.  The Common Gateway Interface (CGI)

B.16. The Common Gateway Interface (CGI)

One of the most popular uses for Perl on the Web is in writing CGI programs. These run on a web server to process the results of a form, perform a search, produce dynamic web content, or count the number of accesses to a web page.

The CGI module, which comes with Perl, provides an easy way to access the form parameters and to generate some HTML in responses. (If you don't want the overhead of the full CGI module, the CGI_Lite module provides access to the form parameters without all the rest.) It may be tempting to skip the module and copy and paste one of the snippets of code that purport to give access to the form parameters, but nearly all of these are buggy.^[*] When writing CGI programs, there are several big issues to keep in mind. These make this topic too broad to fully include in this book:^[]

^[*] There are some details of the interface that these snippets don't support. Trust us; it's better to use a module.

^[] Several of the reviewers who looked over a draft of this book for us wished we could cover more about CGI programming. We agree, but it wouldn't be fair to the reader to give just enough knowledge to be dangerous. A proper discussion of the problems inherent in CGI programming would probably add at least 50% to the size (and cost) of this book.

Security, security, security

We can't overemphasize security. Somewhere around half of the successful attacks on computers around the world involve a security-related bug in a CGI program.

Concurrency issues

It's easy to have several processes concurrently trying to access a single file or resource.

Standards compliance

No matter how hard you try, you probably won't be able to test your program thoroughly with more than about 1% or 2% of the web browsers and servers in use today^[] because thousands of programs are available, with new ones popping up every week. The solution is to follow the standards, so your program will work with all of them.^[*]

^[] Every new release of each browser on each different platform counts as a new one that you're probably not going to be able to test. We chuckle when we hear someone tested a web site with "both browsers" or when they say "I don't know if it works with the other one."

^[*] At the very least, following the standards lets you put the blame squarely on the other programmer, who didn't.

Troubleshooting and debugging

Since the CGI program runs in a different environment than you're likely to be able to access directly, you'll have to learn new techniques for troubleshooting and debugging.

Security, security, security!

There, we've said it again. Don't forget security. It's the first and last thing to think about when your program is going to be available to everyone in the world who wants to try breaking it.

That list didn't mention URI-encoding, HTML entities, HTTP and response codes, Secure Sockets Layer (SSL), Server-Side Includes (SSIs), here documents, creating graphics on the fly, programmatically generating HTML tables, forms, widgets, hidden form elements, getting and setting cookies, path info, error trapping, redirection, taint checking, internationalization and localization, embedding Perl into HTML (or the other way around), working with Apache and mod_perl, and using the LWP module.^[] Most or all of those topics should be covered in any good book on using Perl with the Web. CGI Programming with Perl by Scott Guelich, et al. (O'Reilly) is mighty nice here, as is Lincoln Stein's Network Programming with Perl (Addison-Wesley).

^[] Do you see why we didn't try to fit all of that into this book?