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

Processing and Checking the FORM Data—process_form.pl

When the user completes the FORM , he or she presses the Submit button at the bottom of the page. This FORM uses the POST method to send the data to the gateway program process_form.pl . This program processes the data and checks for obvious errors, such as missing fields, errors in the time and date, and so on. If there are no errors, the program returns a preview of the posted notice for confirmation by the user—an example preview document is shown in Figure 11.12. Notice the “Accept?” yes-or-no checkboxes and the associated Submit button. The entire data content of the notice is stored within <INPUT TYPE=“hidden” ...> elements contained inside the “Yes/No” acceptance FORM. The ACTION of this FORM points to the program deposit_notice.pl, which actually adds the notice to the notices database. If the user decides the notice is acceptable, selects “Yes,” and presses Submit , the data contained within the hidden elements are sent to deposit_notice.pl.

Figure 11.10  The HTML document returned by the program add_notice.pl . This page lists, within an HTML FORM, all the groups under which notices can be deposited. The program add_notice.pl obtains this information by reading a server database.

Processing an Error-Free FORM

As indicated in Figure 11.8, the program deposit_notice.pl is located in a directory (here labeled cgi-secure) different from that containing process_form.pl, deposit_form.pl, and so on—deposit_notice.pl is located in a directory protected by the “Basic” authentication scheme. As soon as a user accesses deposit_notice.pl, he or she is challenged for an authorization username and password. If the username and password information entered by the user are in error, access is immediately refused. If the username/password pair is acceptable because it is a valid pair, the program deposit_notice.pl then checks to make sure this particular user is authorized to deposit under the group being considered— the username and password may be valid, but only for another departmental group (e.g., for the Department of Physiology). The WebNotice system checks the username against a database that matches usernames with groups—if the user is not authorized to submit notices under the Department of Statistics, the program deposit_notice.pl returns the server directive

Status: 401 Not authorized

Figure 11.11  The HTML document returned by the program deposit_form.pl. This document contains a FORM into which the user enters the required notice information. This program is accessed using the GET method (see the URL in the “Location” window), so that this document can be bookmarked for future reference.

which is the HTTP status message indicating authorization failure. The server subsequently returns the 401 header message to the client. In general, the client will tell the user that authorization failed and will give the user the option of trying again with another username and password.

Finally, if the username/password pair is acceptable and the particular user is allowed to deposit notices under the given department, then the notices data are stored in the notices database. The deposited notice can then be retrieved for viewing (list_notices.pl and list_notices_bygroup.pl), modification (modify.pl), or deletion (cancel.pl). The processes of modification and cancellation both pass through programs in the cgi-secure directory, ensuring that authentication is again required before changes are permitted.

Processing a FORM Containing Field Errors—process_form.pl

It is also possible that the data passed to process_form.pl contained errors in the time, date, or other fields. In this case, process_form.pl creates a table of the errors and returns a document containing both a list of these errors and a duplicate fill-in FORM . The input fields of this duplicate FORM contain the data from the user’s first attempt, so the user need only correct the mistakes and not re-enter the entire content. An example of such a document is shown in Figure 11.13.

Figure 11.12  If the FORM in Figure 11.11 is properly completed and submitted, the user is presented with this “preview” of the notice. It contains a small FORM, which the user uses to accept or reject the notice. This FORM contains <INPUT TYPE=“hidden”...> elements that contain the entire data content of the fill-in FORM shown in Figure 11.11.

General Issues in Gateway Program Design

There are many problems that will crop up as you write gateway programs, as is the case with any programming project. This section describes ways to check for four of the more common errors, in this author’s experience, that occur when writing gateway programs. Your list will assuredly be different, but hopefully this section will help you avoid some basic pitfalls!

Check for the Correct HTTP Method

The environment variable REQUEST_METHOD gives the method being used by the browser to access the script. If the method is incorrect (the request used the GET method, but the program expects POST), the program should return an appropriate error message.

Check for Input

The gateway program should always check for the existence of input (if input is expected), either in the QUERY_STRING environment variable or at standard input, depending on the HTTP method. Programs often behave very badly if they

Figure 11.13  The FORM returned by the program process_form.pl if there were errors in the FORM input fields. This document lists the errors at the top and then reproduces the fill-in FORM for correction by the user. This FORM, when submitted, once again accesses the program process_form.pl. The issues involved in assuring that FORM data are safely returned in this second form and in “hidden” elements within a FORM are discussed in the text.

attempt to read nonexistent environment variables or an empty standard input stream. If data are missing, the program should return an appropriate error message.

Check for Errors in Input Fields

Check the input fields for obvious errors and never trust the data sent by a browser. Innocuous errors, such as an unexpected negative number where a positive one was anticipated, can lead to havoc if you haven’t checked for all possible errors.

Remember: Browsers Parse Returned Text

Remember that text returned to a browser inside a NAME or VALUE string or inside a TEXTAREA region, will be parsed and that all character and entity references will be converted into the corresponding ISO Latin-1 characters. If you do not want this to happen, you must encode the ampersand characters in the original data prior to placing the data in the FORM being sent to the client. This issue was discussed in detail in Chapter 10.

Want to Obtain WebNotice?

The WebNotice software package is, like many World Wide Web applications, freely available over the Internet. If you want to find out more about WebNotice, and perhaps obtain your own copy of the software, just access the URL:

www.utoronto.ca/ian/Software/webnotice.html