Passing Information to Your CGI Program

Previous Table of Contents Next

Passing Information to Your CGI Program

When a CGI program is run as the result of a form submission, the field names and values passed in from the form—called parameters—need to be processed by the CGI program. This is done with the param function.

Without any arguments, the param function returns the names of the fields being passed into the CGI program. If the CGI program was accepting the form in Listing 22.1, the param function would return body, sex, name, and submit.

With an argument, param returns the value of that parameter. For example, param('sex') would return the value of the radio buttons—either male or female—depending on which was selected.

Listing 22.2 contains a short CGI program to print these parameters.

Listing 22.2. CGI Program for Printing Parameters

1: #!/usr/bin/perl -w

2: use strict;

3: use CGI qw(:standard);


5: print header;

6: print "<p>The name was", param('name'), "<br/>";

7: print "The sex selected: ", param('sex'), "<br/>";

8: print "The description was:<br/>", param('description'),

9:       "</p>";

If the parameter specified by param is not used in the form, param returns undef.

GET and POST Methods

In the form in Listing 22.1, the <FORM> tag has an attribute called method. The method attribute specifies how the web browser should transmit the data to the web server. Currently, two methods are available.

The first method—also the default method if you don't specify one in the <FORM> tag—is called GET. With the GET method, the form values are passed to the CGI program by having their values encoded in the URL. You may have seen URLs like this while surfing the Web:


The CGI program, when it is run, can decode the remainder of the URL into fields and values. The param function essentially does the same when it's called. You should not try decoding these values yourself. The param function does a thorough job of it, and you don't have any reason to use anything else to extract the values.

The other method, POST, produces exactly the same result but through a different means. Instead of encoding all the form values into the URL, the web server is contacted and the HTML form values are sent as input to the CGI program. Again, you don't need to know at this time exactly how this process works; the CGI module takes care of that for you. Simply calling the param function takes care of reading the values, decoding them, and passing them to your program.

By the Way

You may have downloaded CGI programs from the Internet or seen examples in other books that try to decode an environment variable called QUERY_STRING or use a variable called REQUEST_METHOD to figure out whether the form uses a GET or POST method. Those programs attempt to reproduce the work already done in the standard CGI module—and probably not as well. You should avoid doing this yourself.

So, which method should you choose? Each method has advantages and disadvantages. The GET method allows the web browser to bookmark the particular URL that generated the page. For example, the URL http://www.server.com/cgi-bin/sample.pl?name=foo&desc=Basic%20Forms could be bookmarked and always returned to by the browser. From the perspective of the CGI program—sample.pl—it doesn't know whether you've just come from actually viewing the form. It receives the normal CGI parameters as it always has. Being able to call a CGI program repeatedly using the GET method's URL-encoded values is called idempotency.

However, you might not particularly want browsers to be able to bookmark in your site to run your CGI programs directly, and the URLs for invoking a CGI program with the GET method are, frankly, ugly.

The POST method doesn't encode the form data in the URL at all; it relies on the browser to send the data as it's negotiating for the page. However, because the data isn't encoded into the URL, you can't bookmark a page that was generated by a CGI program using the POST method.

    Previous Table of Contents Next
    © 2000- NIV