CGIs and Perl scripts
We have seen previously what are CGIs and an introduction to Perl scripts. This page puts the two together. This is, however, a very brief overview of the subject emphasizing the process rather than the details of each step of the process. I will use Netscape and the Web Teach Server for the practical examples, but most web servers behave similarly.
Introduction
The request for a CGI is initiated by a web browser (client) when a user selects a link containing an URL especially coded for this purpose. The URL is comprised of six parts:
- protocol (http, ftp, etc)
- hostname (either a FQDN or IP number)
- port (if not the default 80 for HTTP)
- path (the location of the page/CGI on the host)
- parameters (like size, etc, not required)
- argument string (the input to a CGI, if any, preceded by a ? mark.)
The server only sees the last three parts, the first three let the client contact the server. The server replies to the client with header lines and content. The content is whatever the page requested by the client has.The required header lines are:
- first line: protocol version, status code and reason phrase. Example: HTTP/1.0 200 OK
- second line: date and time the server handled the request.
- third line: server software and version
- fourth line: content type: (e.g. text/html)
- fifth line: content-lenght (e.g. 2347)
- last line: a mandatory blank line
In addition with each request the server also receives environment variables that are not request-specific. What the server does with all this information depends upon the server and has a bearing on the CGI programming. As more the server does, less the programmer has to do, and vice-versa.
From this point on we can only discuss CGIs regarding a specific server and a given CGI programming language. In this page we will concentrate in the Netscape (and Apache) web server behavior and the use of Perl scripts to create CGIS, as pointed out before.
CGI support for Perl
- Environment variables: most Web servers provide the environment variables as the associative array %ENV . Therefore, the browser the client is using will be obtained by $ENV{USER_AGENT} ,and the referring document by $ENV{HTTP_REFERER}.
- Request-specific variables: in simple scripts you can use cgi-lib.pl -- a Perl script containing the following subroutines:
- MethGet -- returns 1 if method is GET, 0 otherwise.
- ReadParse -- decodes POST and GET data and reads the name=value pairs into an associative array %in, an array @in, and a scalar $in.
- PrintHeader -- prints the Content-type:text/html for responses.
- PrintVariables and PrintVariablesShort -- to print nicely the name-value pairs.
A CGI Perl script example
You can see here an example of a CGI created in Perl for the Pebble Server in order to collect bug reports and suggestions regarding the server (this script was adapted from the documentation from the WebSite).
You can see the code for the Perl script here. Lets walk through the script and understand how a CGI works.
- It starts including the cgi-lib.pl library described before, so that I could use the subs in this library to process request-specific variables.
- next, it checks if the method is GET or POST and process the request by invoking subroutines.
- the sub ReturnForm prints to STDOUT a form html-marked. The Web server CGI support gets this output and sends it to the client. In some servers you are required to do it, what makes it a little more involved.
- the sub WriteReport starts by opening a file bugs.shtml and assigns it to the filehandle REPORT for append. This is a file in the server to keep the bugs and suggestions.
- next the ReadParse sub (from the cgi-lib.pl library) is invoked to decode the name-value pair submitted on the request.
- then the information is written to the filehandle REPORT (the local file in the server), encoded in HTML.
- finally, an acknowledgement is printed to STDOUT, also HTML encoded. Of course the Web server takes care of sending it to whom it belongs to.
This page is maintained by Al Bento
who can be reached at abento@ubmail.ubalt.edu. This page was last updated on March 5, 2003. Although we will attempt to keep this information accurate, we can not guarantee the accuracy of the information provided.