لطفا منتظر باشید ...
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?
