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 simply 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.[411]
[411]There are some details of the interface that these snippets don't support. Trust us; it's better to use a module.
When writing CGI programs, though, there are several big issues to keep in mind. These make this topic one too broad to fully include in this book:[412]
[412]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 that are 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 that are in use today.[413] That's because there are literally thousands of
different programs available, with new ones popping up every week.
The solution is to follow the standards, so your program will work
with all of them.[414]
[413]Remember that every new release of each brand of browser on each different platform counts as a new one that you're probably not going to be able to test. We really 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."
[414]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.
And that list didn't even mention URI-encoding, HTML entities, HTTP and response codes, Secure Sockets Layer (SSL), Server-side Includes (SSI), here documents, creating graphics on the fly, programmatically generating HTML tables, forms, and 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.[415] 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 & Associates, Inc.) is mighty nice here, as is Lincoln Stein's Network Programming with Perl (Addison-Wesley).
[415]Do you see why we didn't try to fit all of that into this book?
 |  |  |
| B.15. Debugging |  | B.17. Command-Line Options |
Copyright © 2002 O'Reilly & Associates. All rights reserved.