Web Forms: The Third and Final Chapter

Comments

In the past two Gearhead columns, we began to explore the question: "How does a Web server application get data from a form?" This week, we'll wrap it up.

The first week we covered what goes on in an HTTP transaction, and last week we discussed the mechanism of a GET request:

GET /cgi-bin/myapp.pl?search= Gearhead%20columns&hits=10 HTTP/1.0User-Agent: xxxxxxAccept: image/gif, image/jpeg, */*But last week we made a mistake: The form we showed that was supposed to generate the above request was missing the ACTION (the program we want to run -- if you spotted this, award yourself a point). The form should have read:

As we also mentioned last week, GET isn't the only mechanism by which data is passed to a Web server. This is good because the amount of data that can be passed by a GET request is limited by the size of the "environment" made available by the Web server's operating system.

To overcome this restriction, the POST method is available. To use it with the above form, the first line defining the form should read:

Now instead of putting the form data in the requested URL, the data is in the HTTP body (which follows the header we have come to know and love, and a blank line), thusly:

POST /cgi-bin/myapp.pl HTTP/1.0

User-Agent: xxxxxx

Accept: image/gif, image/jpeg, */*

search=Gearhead%20columns&hits=10

Because we don't use the QUERY_STRING environment variable, how does form data get to the application? By the program's standard input (usually written as "STDIN"), which is the way programs receive keyboard input. Let's look at a Perl script to handle our form data:

01 #1/usr/local/bin/perl

02 &parse_form_data (*my_form );

03 print "Content-type: text/plain", "\n\n";04 print "You want ", $my_form {'hits'}, "hits from ", $my_form {'search'},;05 exit(0)Line 1 is a standard bit of Perl we'll gloss over for brevity's sake. The next line is a call to a subroutine called parse_form_data that breaks up the incoming data into key-value pairs and sticks them in an array. The subroutine is smart enough to know the method used in the request and to retrieve the key-value pairs from the right places. It then builds an array, which in our case is called my_form. In Perl this is an associative array, which means we can retrieve items from the array by name.

In terms of complexity, parse_ form_data is not bad because Perl makes such string handling easy. That said, it is long and complex enough to have to leave it at that (if you are interested in the code send a message to parse_form_ data@gibbs.com).

Line 3 is where it gets more interesting. We print to the standard output (called STDOUT), and rather than the data going to the printer, it is handled by the Web server. What we are printing is an HTTP response header. This header says what content type we are returning to the browser and includes a blank line that delimits the header from the response body.

In Line 4 we reference the keys to get the associated values and print them out. Actually there's more to the response header that is, by default, automatically added by the Web server. However, there in three columns is an overview of handling Web forms.

(Responses to gh@gibbs.com.)

Join the newsletter!

Error: Please check your email address.

More about CGI