HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

Example 24: HTML FORMs via a POST Request

This example again accesses the program shown in Figure 10.9 using a FORM equivalent to the one in Figure 9.6, but this time, using the POST method. The data sent to a server (again using the Mosaic for X-Windows browser) are:

POST /cgi-bin/form1 HTTP/1.0
Accept: text/plain
Accept: application/x-html
Accept: application/html
Accept: text/x-html
Accept: text/html
Accept: audio/*
 .
 .
Accept: text/x-setext
Accept: */*
User-Agent: NCSA Mosaic for the X Window System/2.4 libwww/2.12 modified
Content-type: application/x-www-form-urlencoded
Content-length: 58

srch=dogfish&srch_type=Exact+Match&srvr=Canada&srvr=Sweden

In this case, the data are sent to the server as an encoded message following the headers. There are two extra header fields: the content-length field, which tells the server the length of the following message; and the content-type field, which tells the server that this is an application/x-www-form-urlencoded MIME type—this is the MIME type that indicates FORM data that have been encoded using the URL encoding scheme.

if( !defined($ENV{“QUERY_STRING”})) {  # Check for Query String environment
    &pk_error(“No Query String\n”);    # Variable -- if absent, then error.
}
$input=$ENV{“QUERY_STRING”}            # get FORM data from query string

                                       # Check for unencoded equals sign -- if
                                       # there are none, the string didn’t
if( $input !~ /=/ ) {                  # come from a FORM, which is an error.
  &pk_error(“Query String not from FORM\n”);
}
                                       # If we get to here, all is OK. Now
@fields=split(“&”,$input);             # split data into separate name=value
                                       # fields(@fields is an array)

#   Now loop over each of the entries in the @fields array and break
#   them into the name and value parts. Then decode each part to get
#   back the strings typed into the form by the user

foreach $one (@fields) {
   ($name, $value) = split(“=”,$one);   # split, at the equals sign, into
                                        # the name and value strings. Next,
                                        # decode the strings.
   $name  =~ s/\+/ /g;                  # convert +’s to spaces
   $name  =~ s/%(..)/pack(“c”,hex($1))/ge;    # convert URL hex codings to Latin-1
   $value =~ s/\+/ /g;                   # convert +’s to spaces
   $value =~ s/%(..)/pack(“c”,hex($1))/ge;    # convert URL hex codings to Latin-1

#    What you do now depends on how the program works. If you know that
each
#    name is unique (your FORM does not have checkbox or SELECT items
that
#    allow multiple name=value strings with the same name) then you can
place
#    all the data in an associative array (a useful little perl fea-
ture!):

Figure 10.12  Data returned from the script shown in Figure 10.9 when accessed by the FORM shown in Figure 9.6 and modified to use the POST HTTP method.

Figure 10.12 shows the results returned by the script in Figure 10.9 and displays the data that arrived at the script. There are no command-line arguments this time, because there is no query string. Most of the environment variables are the same as with the GET request shown in Figure 10.10. Obvious differences are the REQUEST_METHOD variable, which is now POST instead of GET, and the null QUERY_STRING. In addition, the CONTENT_TYPE and CONTENT_LENGTH are not empty but contain the length of the message and the content-type, as indicated in the fields sent by the client.

Where are the FORM data? With the POST method, these data are sent to the gateway program as an input stream, which the program reads from standard input. The script in Figure 10.9 reads data from standard input and prints the results back to standard output. The result is printed at the bottom of Figure 10.12, which clearly shows the query data sent by the client. These data are encoded using the same URL encoding mechanisms employed with the GET query in Figure 10.10. To further process these data, you must parse it and separate the fields. Figure 10.13 shows an extract of a perl program that illustrates how this decoding can be done. This is similar to the code in Figure 10.11—the differences occur only at the beginning of the script and are marked in italics. Again, there are CGI libraries, mentioned in Chapter 11, that can help in the processing of these data.

Example 24 may seem similar to Example 23, but it is, in fact, different in important ways. First, many computer operating systems limit the size of environment variables, so that large messages passed via GET URLs may be truncated. In addition, the POST method allows for complicated MIME messages to be sent from client to server, something that is impractical, if not impossible, with the GET method. In this regard, data can be POSTed to a server using the multipart/form-data encoding scheme, discussed in Example 18 in Chapter 9. This scheme supports file upload (the ability to upload arbitrary data files from the client to the server) as well as the encoding of text input using any character set—recall that URLs, and hence URL-encoded FORM data, are restricted to the ISO Latin-1 character set.