Introduction to Cgi/Perl: Getting Started With Web Scripts - Softcover

Brenner, Steven E.; Aoki, Edwin

Softcover

ISBN 10: 1558514783 ISBN 13: 9781558514782

Publisher: M & T Books, 1995

Synopsis

A compact guide to creating customized programs for the World Wide Web, which introduces the essentials of Perl language and the Common Gateway Interface (CGI), then quickly moves on to cover forms and "comboforms." Topics include information-gathering and reporting with HTML and forms; customized client-server interaction with HTTP, including explanations of protocol nuances such as GET and POST; and text processing and management with the Perl language. Annotation c. by Book News, Inc., Portland, Or.

About this title

Review:

An important guide for developing dynamic content and forms to add impact and interaction to Web sites. Brenner is the author of cgi-lib.pl, the de facto standard library for creating CGI scripts with Perl. Used for everything from NASA space data to Byte Magazine's on-line comment box, this library makes CGI scripting intuitive and fun.

If you want to see an excerpt from this book, look below, or click on the title.

Excerpt. © Reprinted by permission. All rights reserved.:

The following is a short essay from the book for recognizing scripts.

Recognizing a Script When You See It

How does a server tell that a CGI script is a script and not a document file? Often, without some help from the script writer, it can't. In fact, one of the most common errors encountered by CGI programmers is the failure to provide the hints necessary for the server to make this distinction. A confused server may generate a variety of different errors, depending upon how the server is configured and how the script was called. The most common result is that the text of the script (i.e., its source code, as in Listing 1.2) is output, rather than the result of its execution. You might also receive errors like "can't POST to non-script"- this message is particularly infuriating because posting to a script is exactly what you are trying to do.

These problems arise because there are no set standards for how a server should recognize a CGI script; consequently, different servers work in different ways. A model used by both the NCSA and CERN servers is to have a special directory in which all scripts (and only scripts) reside. The actual location of the directory on the disk and the name by which it is accessed over the Web (typically /cgi-bin) are specified in configuration files. Any request for a document in that directory or its subdirectories is treated as a request to execute that document as a script. Most servers support this model.

A newer approach is to use a filename extension to recognize CGI scripts, mirroring the technique used to determine a file's Media Type. The precise extension (and indeed the ability to have the extension specify a CGI script) is typically defined as part of the server's configuration. The most common extension for scripts is .cgi, though most Windows servers use the extensions .exe or .pl, and recent versions of Macintosh servers have used .acgi.

The use of extensions means that the CGI scripts can reside anywhere in the server's directory space, which has benefits and drawbacks. On the plus side, it means that scripts can be kept in intuitive locations, near related HTML files and other documents. On the minus side, spreading scripts all over the directory hierarchy makes it harder to keep track of all of them, in case they need to be updated. More importantly, if the server is configured to allow access to documents in users' personal directories (typically by mapping URLs with ~username to ~username/public_html), anyone can create and execute their own CGI scripts. While this may be appealing, it is common for inexperienced users to inadvertently write CGI programs with major security holes (especially if using shell scripts). Thus, a single user can potentially jeopardize the security of an entire server computer.

For these reasons, many servers come with extension-based CGI script recognition disabled by default. Even if enabled, many Internet service providers explicitly prohibit CGI scripts in users' space to avoid security hassles. If you try to run a CGI script in an area of the server where their use is not permitted, you may receive an access denied error. This message can be confusing as it also appears when a file's permissions are set incorrectly. Refer to Appendix A for additional troubleshooting hints.

Only a server can interact with a script. A client program cannot directly run (e.g., with the "open file" command) a CGI script; if asked to do so, the browser will likely display the script's source code. Because CGI communications take place between a server and a script, every CGI interaction must involve an HTTP server.

More information can be found at www.mispress.com/introcgi/ the Online Appendix to the book. While this Online Appendix was especially designed to complement the book, it can serve as a useful resource for anyone interested in CGI and Perl. In addition to current information about CGI, Perl, and the Web, you can also find downloadable code, pointers to the Perl distribution, and links to other helpful sites. It also has a mirror of the homepage for cgi-lib.pl, the de facto standard library for creating CGI scripts with Perl.

About this edition

• Publisher: M & T Books
• Publication date: 1995
• ISBN 10: 1558514783
• ISBN 13: 9781558514782
• Binding: Paperback
• Number of pages: 151