Beginner Tip:
Form Processing Basics

by Larisa Thomason,
Senior Web Analyst,
NetMechanic, Inc.

Popular HTML editors make it really easy to include forms on your Web site. Just place a few textboxes, checkboxes, and a submit button and you're done. Or are you?

The form data still needs to be processed. That's where many beginning webmasters run into problems. We'll answer some of the most common questions about attributes, CGI scripts, and other options for form processing.

What does the term "form processing" mean, anyway?

There are two sides to form processing: the client-side and the server-side.

The client-side is the actual form that a visitor sees on your Web page. The form accepts the information entered by the user and the browser sends the data to the server for processing.

The server-side is a little more complicated, mainly because you have so many options for form processing. When the browser sends the form data to the server, it (the browser) assumes the server knows what to do with it. The server relies on you, the webmaster, to provide those instructions.

If you don't, the user may see an error message. Even worse, the form may seem to submit without a problem, but nothing really happens on the server-side. Keep this from happening by becoming familiar with the attributes that go with the FORM tag, what they mean, and what they do.

What is the ACTION attribute?

The ACTION attribute specifies the URL that will receive and process the form data. Use ACTION to send the form to a processing script or to email the form data, like this:

Note: when you use a MAILTO address with the ACTION attribute, no other processing takes place. The browser sends an email to the address (or addresses) you specify, but the form data isn't saved anywhere else. Also, some browsers don't recognize MAILTO links.

When visitors take the time to fill out a form, most won't appreciate it much if you waste their time.

So how do I send an email AND get the form to process at the same time?

Some sort of form-mail script works best for this. These are usually short CGI scripts that are installed on the server-side. Check with your Web host because the vast majority of hosting companies give clients access to one or more form processing scripts. If your host doesn't, it may be time to look for a new Web host!

The CreativeProgrammers Web site offers a quick form-mail script tutorial that explains how a form-mail script works.

Depending on your Web host and the complexity of your form, you may want to sign up with an online form-hosting service. These companies remotely host your forms. Your forms appear on your Web site, but the form data is processed by the form host's server instead of your own Web host. Most companies charge a fee for this service that ranges from about $20 per year to $100 or more.

A form-hosting service may be a good idea for a beginning webmaster who needs to generate really complicated forms (like multi-page forms), write the information to a database, or conduct other kinds of specialized processing.

How does the form data get sent?

You decide that and set up the process using the METHOD attribute.

The ACTION attribute defines how the form will be processed and the method attribute defines how the form data will be sent. Use METHOD to tell the browser which HTTP method to use to submit the form data.

METHOD has two possible values: GET and POST.

What's the difference between POST and GET?

With POST, you send the contents of the form as a data stream. Form data sent using GET becomes part of the URL.

POST separates the form data from the URL and includes it in another part of the HTTP request to the server. JavaScript functions and many CGI scripts that process forms require you to use the POST method.

Although GET is the default, it's an older method that's deprecated (marked for deletion in future HTML versions) in HTML 4.0.

POST is often the preferred way to send information especially if it's sensitive data or contained in a particularly long form.

My HTML book says to never use method="get." Why?

Besides being deprecated, GET is less secure. It adds all the form data to the URL and sends it all to be processed.

The URL of a form processed using GET looks like this:

http://www.YourDomain.com/cgi-bin/query?    Fname=Brian&Lname=Magoo&comments=Comments

The question mark precedes the form data and the ampersand sign separates the values of the different form fields.

That raises two serious issues:

Security: All the form data is appended to the URL. Consider the information you often put into a form: name, address, phone number, email address, credit card information. Do you really want it sailing around unprotected on the Web? Size: If you're sending a large amount of form data, some of the data may get dropped. GET's size limitation depends on the server where the form is hosted. It can be as little as 256 bytes, while others accept as much as 32k.

Many Web reference sources advise you to avoid GET entirely. We disagree.

Is GET ever a good way to submit form data?

Yes! There are times when GET really is the best option.

The GET method is particularly useful for online search functions. Since GET adds the form data to the URL, searchers are able to bookmark and save the URL with the form data. We use it for our search functions here at the NetMechanic site.

Search engines and the search functions on individual Web sites often use the GET method for just this reason. It gives searchers the opportunity to save the search results for later reference.

Another reason for using GET is to avoid problems when your visitors use the Back button on their browser. Using the POST method will generate a warning message like the one shown below if visitors try to return to the form results page.

This warning occurs because the POST method has some extra security mechanisms that prevent it from resending data without the visitor's express consent.

Unfortunately the warning usually just confuses visitors, who end up hitting the Refresh button and resending the form data anyway.

Avoiding this warning is a big part of the reason we at NetMechanic use the GET method whenever possible.

How do I send visitors to a confirmation page after they submit the form?

The easy way is to put the confirmation page URL as the value for the ACTION attribute. But there's a problem. The form data doesn't get stored anywhere else because you haven't specified any sort of processing script or action.

Your form-mail script should include an option to send visitors to a customized confirmation or thank-you page. Many require you to include the URL of the confirmation page inside your form using a hidden field. That's a field that the visitor doesn't see on the Web page, but is used to process form data or save form information for use on another Web page.

A hidden field that specifies a confirmation page looks like this:

<input type="hidden" name="ThankYou" value="http://YourDomainName.com/ThankYou.htm">

I use FrontPage for my forms. Why do I care about this?

FrontPage is a good WYSIWYG editor for beginners. They can quickly lay out and post a working Web site without actually writing any HTML code themselves. The downside is that webmasters give up a lot of control and may have problems debugging the editor-generated pages.

HTML Toolbox checks your HTML code for errors and alerts you to browser-specific HTML tags that may break your page in some browsers. It works whether you've hand-coded your page or used an editor like FrontPage. But you also need to be alert to editors that add their own proprietary tags to certain page elements.

FrontPage uses proprietary tags called "webbots" to process forms. The webbot feature makes FrontPage forms easy to set up and use, but they only work on servers that have the FrontPage extensions installed. If you use the webbot feature for forms, you're limited to Web hosts who offer FrontPage extensions on their servers.

There's absolutely nothing inherently bad about FrontPage forms or extensions. They work great for most users. But realize that if you only know how to use FrontPage webbots to create forms, then you're tying yourself to one editor, restricting your choice of Web hosts, and limiting your form processing options.

Avoid this problem by creating forms in FrontPage that don't use the webbots. It will be easy to do now that you understand how forms process!

If you'd like to learn more about individual form elements and how to use them in a form, check out this HTML form tutorial by William Bontrager. There's a short online version and a downloadable PDF version that's longer and more complete.