19.2 The FORM Element

HTML forms allow you to create a set of data input elements associated with a particular URL. Each of these elements is typically given a name in the HTML source code, and each has a value based on the original HTML or user input. When the form is submitted, the names and values of all active elements are collected into a string with = between each name and value and with & between each name/value pair. This string is then transmitted to the URL designated by the FORM element. The string is either appended to the URL after a question mark or sent on a separate line after the HTTP request headers and a blank line, depending on whether GET or POST is used as the submission method. This section covers the FORM element itself, used primarily to designate the URL and to choose the submission method. The following sections cover the various user interface controls that can be used within forms.

HTML Element: <FORM ACTION="..." ...> ... </FORM>

Attributes: ACTION , METHOD , ENCTYPE , TARGET , ONSUBMIT , ONRESET , ACCEPT , ACCEPT-CHARSET

The FORM element creates an area for data input elements and designates the URL to which any collected data will be transmitted. For example:

 <FORM ACTION="http://some.isp.com/someWebApp/SomeServlet">  FORM input elements and regular HTML  </FORM> 

The rest of this section explains the attributes that apply to the FORM element: ACTION , METHOD , ENCTYPE , TARGET , ONSUBMIT , ONRESET , ACCEPT , and ACCEPT-CHARSET . Note that we do not discuss attributes like STYLE , CLASS , and LANG that apply to general HTML elements, but only those that are specific to the FORM element.

ACTION

The ACTION attribute specifies the URL of the server-side program that will process the FORM data (e.g., http://www.whitehouse.gov/servlet/schedule-fund-raiser ). If the server-side program is located on the same server from which the HTML form was obtained, we recommend using a relative URL instead of an absolute URL for the action. This approach lets you move both the form and the servlet to a different host without editing either. This is an important consideration since you typically develop and test on one machine and then deploy on another. For example,

 ACTION="/servlet/schedule-fund-raiser" 

Core Approach

If the servlet or JSP page is located on the same server as the HTML form, use a relative URL in the ACTION attribute.

In addition, you can specify an email address to which the FORM data will be sent (e.g., mailto:[e-mail] ). Some ISPs do not allow ordinary users to create server-side programs, or they charge extra for this privilege. In such a case, sending the data by email is a convenient option when you create pages that need to collect data but not return results (e.g., for accepting orders for products). You must use the POST method (see METHOD in the following subsection) when using a mailto URL.

Also, note that the ACTION attribute is not required for the FORM element. If you omit ACTION , the form data is sent to the same URL as the form itself. See Section 4.8 for an example of the use of this self-submission approach.

METHOD

The METHOD attribute specifies how the data will be transmitted to the HTTP server. When GET is used, the data is appended to the end of the designated URL after a question mark. For an example, see Section 19.1 (How HTML Forms Transmit Data). GET is the default and is also the method that is used when the user types a URL into the address bar or clicks on a hypertext link. When POST is used, the data is sent on a separate line. Either GET or POST could be preferable, depending on the situation.

Since GET data is part of the URL, the advantages of GET are that you can do the following:

• Save the results of a form submission. For example, you can submit data and bookmark the resultant URL, send it to a colleague by email, or put it in a normal hypertext link. The ability to bookmark the results page is the main reason google.com, yahoo.com, and other search engines use GET .

• Type data in by hand. You can test servlets or JSP pages that use GET simply by entering a URL with the appropriate data attached. This ability is convenient during initial development.

Since POST data is not part of the URL, the advantages of POST are that you can do the following:

• Transmit large amounts of data. Many browsers limit URLs to a few thousand characters , making GET inappropriate when your form must send a large amount of data. Since HTML forms let you upload files from the client machine (see Section 19.7), sending multiple megabytes of data is quite commonplace. Only POST can be used for this task.

• Send binary data. Spaces, carriage returns, tabs, and many other characters are illegal in URLs. If you upload a large binary file, it would be a time-consuming process to encode all the characters before transmission and decode them on the other end.

• Keep the data private from someone looking over the user's shoulder. HTML forms let you create password fields in which the data is replaced by asterisks on the screen. However, using a password field is pointless if the data is displayed in clear text in the URL, letting snoopers read it by peering over the user's shoulder or by scrolling through the browser's history list when the user leaves the computer unattended. Note, however, that POST alone provides no protection from someone using a packet sniffer on the network connection. To protect against this type of attack, use SSL ( https :// connections) to encrypt the network traffic. For more information on using SSL in Web applications, see the chapters on Web application security in Volume 2 of this book.

To read GET or POST data from a servlet, you call

 request.getParameter("name") 

where name is the value of the NAME attribute of the input element in the HTML form. For additional details, see Chapter 4 (Handling the Client Request: Form Data). Note that, if needed, you can also use request.getInputStream to read the POST data directly, as below.

 int length = request.getContentLength(); if (length > SOME_MAXSIZE) {    throw new IOException("Possible denial of service attack"); } byte[] data = new byte[length]; ServletInputStream inputStream =  request.getInputStream()  ; int read = inputStream.readLine(data, 0, length); 

ENCTYPE

This attribute specifies the way in which the data will be encoded before being transmitted. The default is application/x-www-form-urlencoded . The encoding, as specified by the World Wide Web Consortium, is UTF-8, except that the client converts each space into a plus sign (+) and each other non- alphanumeric character into a percent sign (%) followed by the two hexadecimal digits representing that character in the browser's character set. These transformations are in addition to placing an equal sign ( = ) between entry names and values and an ampersand ( & ) between the pairs.

For example, Figure 19-5 shows a version of GetForm.html (Listing 19.1) where " Larry (Java Hacker?) " is entered for the first name. As can be seen in Figure 19-6, this entry is sent as " Larry+%28Java+Hacker%3F%29 ". That's because spaces become plus signs, 28 is the ASCII value (in hex) for a left parenthesis, 3F is the ASCII value of a question mark, and 29 is a right parenthesis.

Figure 19-5. Customized result of GetForm.html .

Figure 19-6. HTTP request sent by Internet Explorer 6.0 when submitting GetForm.html with the data shown in Figure 19-5.

Note that, unless otherwise specified, POST data is also encoded as application/x-www-form-urlencoded .

Most recent browsers support an additional ENCTYPE of multipart/form-data . This encoding transmits each field as a separate part of a MIME-compatible document. To use this ENCTYPE , you must specify POST as the method type. This encoding sometimes makes it easier for the server-side program to handle complex data, and it is required when you are using file upload controls to send entire documents (see Section 19.7). For example, Listing 19.3 shows a form that differs from GetForm.html (Listing 19.1) only in that

 <FORM ACTION="http://localhost:8088/SomeProgram"> 

has been changed to

 <FORM ACTION="http://localhost:8088/SomeProgram"     ENCTYPE="multipart/form-data" METHOD="POST"> 

Figures 19-7 and 19-8 show the results.

Listing 19.3 MultipartForm.html

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD>   <TITLE>Using ENCTYPE="multipart/form-data"</TITLE> </HEAD> <BODY BGCOLOR="#FDF5E6"> <CENTER> <H2>Using ENCTYPE="multipart/form-data"</H2> <FORM ACTION="http://localhost:8088/SomeProgram"  ENCTYPE="multipart/form-data" METHOD="POST"  >   First name:   <INPUT TYPE="TEXT" NAME="firstName" VALUE="Joe"><BR>   Last name:   <INPUT TYPE="TEXT" NAME="lastName" VALUE="Hacker"><P>   <INPUT TYPE="SUBMIT"> </FORM> </CENTER> </BODY></HTML> 

Figure 19-7. Initial result of MultipartForm.html .

Figure 19-8. HTTP request sent by Netscape 7.0 when submitting MultipartForm.html .

TARGET

The TARGET attribute is used by frame-capable browsers to determine which frame cell should be used to display the results of the servlet, JSP page, or other program handling the form submission. The default is to display the results in whatever frame cell contains the form being submitted.

ONSUBMIT and ONRESET

These attributes are used by JavaScript to attach code that should be evaluated when the form is submitted or reset. For ONSUBMIT , if the expression evaluates to false , the form is not submitted. This case lets you invoke JavaScript code on the client that checks the format of the form field values before they are submitted, prompting the user for missing or illegal entries.

ACCEPT and ACCEPT-CHARSET

These attributes are new in HTML 4.0 and specify the MIME types ( ACCEPT ) and character encodings ( ACCEPT-CHARSET ) that must be accepted by the servlet or other program processing the form data. The MIME types listed in ACCEPT can also be used by the client to limit which file types are displayed to the user for file upload elements.