This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
"; print "Server Name: ", $ENV{'SERVER_NAME'}, "
", "\n"; print "Running on Port: ", $ENV{'SERVER_PORT'}, "
", "\n"; print "Server Software: ", $ENV{'SERVER_SOFTWARE'}, "
", "\n"; print "Server Protocol: ", $ENV{'SERVER_PROTOCOL'}, "
", "\n"; print "CGI Revision: ", $ENV{'GATEWAY_INTERFACE'}, "
", "\n"; print "
", "\n"; print "", "\n"; exit (0); Let's go through this program step by step. The first line is very important. It instructs the server to use the Perl interpreter located in the /usr/local/bin directory to execute the CGI program. Without this line, the server won't know how to run the program, and will display an error stating that it cannot execute the program. Once the CGI script is running, the first thing it needs to generate is a valid HTTP header, ending with a blank line. The header generally contains a content type, also known as a MIME type. In this case, the content type of the data that follows is text/html. After the MIME content type is output, we can go ahead and display output in HTML. We send the information directly to standard output, which is read and processed by the server, and then sent to the client for display. Five environment variables are output, consisting of the server name (the IP name or address of the machine where the server is running), the port the server is running on, the server software, and the HTTP and CGI revisions. In Perl, you can access the environment variables through the %ENV associative array, keyed by name. A typical output of this program might look like this: <TITLE>About this Server Server Name: bu.edu Running on Port: 80 Server Software: NCSA/1.4.2 Server Protocol: HTTP/1.0 CGI Revision: CGI/1.1
", qq|Click here to run again!|, "\n"; print "", "\n"; exit (0); This program displays the current time, as well as a hypertext link to itself. If you click on the link to run the program again, the date and time that is displayed should change, but it does not, because the browser is retrieving the cached document. You need to explicitly tell the browser to reload the document if you want to run the CGI program again. Fortunately, there is a solution to this problem. If you don't want a virtual document to be cached, you can use the Expires and/or Pragma headers to instruct the client not to cache the document. #!/usr/local/bin/perl print "Content-type: text/html", "\n"; print "Pragma: no-cache", "\n\n"; . . . or #!/usr/local/bin/perl print "Content-type: text/html", "\n"; print "Expires: Wednesday, 27-Dec-95 05:29:10 GMT", "\n\n"; . .
. However, some browsers don't handle these headers correctly, so don't rely on them.
Server Redirection
Status Codes
Chapter 3 Output from the Common Gateway Interface
3.7 Status Codes Status codes are used by the HTTP protocol to communicate the status of a request. For example, if a document does not exist, the server returns a "404" status code to the browser. If a document has been moved, a "301" status code is returned. CGI programs can send status information as part of a virtual document. Here's an arbitrary example that returns success if the remote host name is bu.edu, and failure otherwise: #!/usr/local/bin/perl $remote_host = $ENV{'REMOTE_HOST'}; print "Content-type: text/plain", "\n"; if ($remote_host eq "bu.edu") { print "Status: 200 OK", "\n\n"; print "Great! You are from Boston University!", "\n"; } else { print "Status: 400 Bad Request", "\n\n"; print "Sorry! You need to access this from Boston University!", "\n"; } exit (0); The Status header consists of a three-digit numerical status code, followed by a string representing the code. A status value of 200 indicates success, while a value of 400 constitutes a bad request. In addition to these two, there are numerous other status codes you can use for a variety of situations, ranging from an unauthorized or forbidden request to internal system errors. Table 3.3 shows a list of some of commonly used status codes. Table 3.3: HTTP Status Codes Status Code Message 200 Success 204 No Response 301 Document Moved 401 Unauthorized 403 Forbidden 404 Not Found 500 Internal Server Error 501
Not Implemented
For a complete listing of status codes, see: http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTRESP.html Unfortunately, most browsers do not support all of them.
The "No Response" Code One status code that deserves special attention is status code 204, which produces a "no response." In other words, the browser will not load a new page if your CGI program returns a status code of 204: #!/usr/local/bin/perl print "Content-type: text/plain", "\n"; print "Status: 204 No Response", "\n\n"; print "You should not see this message. If you do, your browser does", "\n"; print "not implement status codes correctly.", "\n"; exit (0); The "no response" status code can be used when dealing with forms or imagemaps. For example, if the user enters an invalid value in one of the fields in a form or clicks in an unassigned section of an imagemap, you can return this status code to instruct the client to not load a new page.
The "Expires" and "Pragma" Headers
Complete (Non-Parsed) Headers
Chapter 3 Output from the Common Gateway Interface
3.8 Complete (Non-Parsed) Headers Thus far, we've only seen examples with partial HTTP headers. That is, when all you include is a Content-type header, the server intercepts the output and completes the header information with header information of its own. The header information generated by the server might include a "200 OK" status code (if you haven't overridden it with a Status header), the date and time, the version of the server, and any other information that it thinks a browser might find useful. But as we mentioned in Chapter 1 CGI programs can override the header information generated by the server by generating a complete HTTP header on its own. Why go to all the trouble of generating your own header? When your program returns a complete HTTP header, there is no extra overhead incurred by the server. Instead, the output of the CGI program goes directly to the client, as shown in Figure 3.2. This may mean faster response time for the user. However, it also means you need to be especially careful when generating your own headers, since the server won't be able to circumvent any errors. Figure 3.2: Partial and complete headers [Graphic: Figure 3-2]
How does the server know if the CGI program has output a partial or a complete HTTP header without "looking" at it? It depends on which server you use. On the NCSA and CERN servers, programs that output complete headers must start with the "nph-" prefix (e.g., nph-test.pl), which stands for Non-Parsed Header. The following example illustrates the usefulness of creating an NPH script: #!/usr/local/bin/perl $server_protocol = $ENV{'SERVER_PROTOCOL'}; $server_software = $ENV{'SERVER_SOFTWARE'}; print "$server_protocol 200 OK", "\n"; print "Server: $server_software", "\n"; print "Content-type: text/plain", "\n\n"; print "OK, Here I go. I am going to count from 1 to 50!", "\n"; $| = 1; for ($loop=1; $loop <= 50; $loop++) {
print $loop, "\n"; sleep (2); } print "All Done!", "\n"; exit (0); When you output a complete header, you should at least return header lines consisting of the HTTP protocol revision and the status of the program, the server name/version (e.g., NCSA/1.4.2), and the MIME content type of the data. You can run this program by opening the URL to: http://your.machine/cgi-bin/nph-count.pl When you run this CGI script, you should see the output in "real time": the client will display the number, wait two seconds, display the next number, etc. Now remove the complete header information (except for Content-type), change the name to count.pl (instead of nph-count.pl), and run it again. What's the difference? You will no longer see the output in "real time"; the client will display the entire document at once.
Status Codes
Forms and CGI
Chapter 4
4. Forms and CGI Contents: HTML Tags Sending Data to the Server Designing Applications Using Forms in Perl Decoding Forms in Other Languages As we discussed briefly in Chapter 4, Forms and CGI forms are generally used for two purposes: data collection and interactive communication. You can conduct surveys or polls, and present registration or online ordering information through the use of forms. They are also used to create an interactive medium between the user and the Web server. For example, a form can ask the user to select a document out of a menu, whereby the server returns the chosen document. The main advantage of forms is that you can use them to create a front end for numerous gateways (such as databases or other information servers) that can be accessed by any client without worrying about platform dependency. On the other hand, there are some shortcomings with the current implementation: ● The interface does not support any data types besides the general "text" type. The next HTML specification could contain other data types, such as "int," "date," "float," and "url." ● User input cannot be checked on the client side; the user has to press the Submit button and the CGI program on the server side has to make sure the input is valid. This chapter covers: ● The HTML tags for writing forms ● How form data is sent to the server ● Examples of designing form-based CGI applications, both in Perl and other languages
4.1 HTML Tags A form consists of two distinct parts: the HTML code and the CGI program. HTML tags create the visual representation of the form, while the CGI program decodes (or processes) the information contained within the form. Before we look at how CGI programs process form information, let's understand how a form is created. In this section, we'll cover the form tags and show examples of their use.
The FORM Tag Here is the beginning of a simple form:
There are many links to various CGI documents throughout the Web, so feel free to explore. . . .
Shishir Gundavaram WWW Software, Inc. White Street 90 Sherman Street Boston, Massachusetts 02115 Cambridge, Massachusetts 02140 [email protected] The address information was last modified Friday, 22-Dec-95 12:43:00 EST.You can include the contents of this file in any other HTML document with the following command: This will include address.html located in the current directory into another document. You can also use the virtual parameter with the include command to insert a file from a directory relative to the server root: For our final example, let's include a boilerplate file that contains embedded SSI directives. Here is the address file (address.shtml) with an embedded echo command (note the .shtml extension):
Shishir Gundavaram WWW Software, Inc. White Street 90 Sherman Street Boston, Massachusetts 02115 Cambridge, Massachusetts 02140 [email protected] The address information was last modified on .When you include this address file into an HTML document, it will contain your signature along with the date the file was last modified.
In this example, we use the UNIX finger command to retrieve some information about the user. SSI allows us to pass command-line arguments to the external programs. If you plan to use environment variables as part of an argument, you have to precede them with a dollar sign. The reason for this is that the server spawns a shell to execute the command, and that's how you would access the environment variables if you were programming in a shell. Here is what the output will look like, assuming REMOTE_USER and REMOTE_HOST are "shishir" and "bu.edu", respectively: Welcome shishir. Here is some information about you:
[bu.edu] Trying 128.197.154.10... Login name: shishir In real life: Shishir Gundavaram Directory: /usr3/shishir Shell: /usr/local/bin/tcsh Last login Thu Jun 23 08:18 on ttyq1 from nmrc.bu.edu:0. New mail received Fri Dec 22 01:51:00 1995; unread since Thu Dec 21 17:38:02 1995 Plan: Come on, aren't you done with the book yet?You should enclose the output from an external command in a
..block, so that whitespace is preserved. Also, if there is any HTML code within the data output by the external program, the browser will interpret it! (To use the exec directive, remember that you need to enable Exec in the Options line of the access.conf file, as described in the "Configuration" seciton earlier in this chapter.) Having the ability to execute external programs makes things easier, but it also poses a major security risk. Say you have a "guestbook" (a CGI application that allows visitors to leave messages for everyone to see) on a server that has SSI enabled. Most such guestbooks around the Net actually allow visitors to enter HTML code as part of their comments. Now, what happens if a malicious visitor decides to do some damage by entering the following:
The current time is: $date_time