2020ok  Directory of FREE Online Books and FREE eBooks

Free eBooks > Computers & Internet > Web Development > HTML, Graphics, & Design > Web Graphics > Introduction to CGI / Perl: Getting Started with Web Scripts

Introduction to CGI / Perl: Getting Started with Web Scripts

by Steven E. Brenner and Edwin Aoki


Download Book
(Respecting the intellectual property of others is utmost important to us, we make every effort to make sure we only link to legitimate sites, such as those sites owned by authors and publishers. If you have any questions about these links, please contact us.)


link 1



About Book

Amazon.com
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.

Book Description
This book teaches readers all they need to know to create custom programs for the World Wide Web. Introduction to CGI/Perl: Getting Started with Web Scripts begins with a complete review of communication technology and then introduces the essentials of the Perl language and the Common Gateway Interface (CGI). It features detailed coverage of all HTML form elements, text processing, management with Perl, receiving input and producing output, and customized client-server interaction with http; including explanations of protocol nuances such as GET and POST. All code and extra examples are available from an online appendix.

The following text is Copyright 1996 Steven E. Brenner & Edwin Aoki an M&T Books. Reprinted by permission of M&T Books, a division Henry Holt and Co. 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.

Comments

SEND A COMMENT

PLEASE READ: All comments must be approved before appearing in the thread; time and space constraints prevent all comments from appearing. We will only approve comments that are directly related to the article, use appropriate language and are not attacking the comments of others.

Message (please, no HTML tags. Web addresses will be hyperlinked):

Related Free eBooks

Related Tags

DIGG This story   Save To Google   Save To Windows Live   Save To Del.icio.us   diigo it   Save To blinklist
Save To Furl   Save To Yahoo! My Web 2.0   Save To Blogmarks   Save To Shadows   Save To stumbleupon   Save To Reddit