The FORM tag is a container tag that requires both a start and end tag, has three possible attributes, and always takes the following basic form:
<FORM [ACTION=url] [METHOD=method] [ENCTYPE=mime-type]>
Form elements and HTML elements...
Forms may not be nested, but may contain any other standard HTML tags including (but not limited to) text attribute tags, tables, images, line breaks, horizontal rules, etc.
The ACTION attribute specifies the URL of the script that is to recieve the forms input. If a URL is not given or the ACTION attribute is not used, the base (current) URL is used.
The METHOD attribute specifies the method to be used for passing the form data to the URL specified by the ACTION attribute. The 2 possible methods are GET and POST, both of which are discussed in more detail below. If a method is not given, or the METHOD attribute is not used, the GET method is used by default.
The ENCTYPE attribute specifies the encoding type to be used in encoding the form data. At present, only one type formally exists and is used by default when this attribute is not used. That type is application/x-www-form-urlencoded. URL encoding is discussed in section V.A. of the lecture.
Whlie both the GET and the POST method encode the form data in the same way (URL encoding), the designation and the method of transmission differs. GET is designated for use in instances where changes are NOT made, for example, when searching a database for a specified record. POST, on the other hand, is designated for use when changes are to be made, for example when adding or modifying a record in a database.
When using the GET method, the URL encoded data is tacked onto the end of the URL with a question mark (?) as in:
In this case, a script must retrieve the URL encoded data as if it were reading in command line parameters. When using POST, the data gets sent seperately as in:
POST /cgi-bin/output.cgi HTTP/1.0
User-agent: Why, it's LoneWolf... that's who! 8^)
In the case of POST, a script (that specified by the ACTION attribute) must read in the data from STDIN (unless otherwise specified).
In both cases, POST is now recommended by the powers that be because the GET method has some characteristics that can be problematic. One such problem is in the case where a system may have a finite length allowed on the command line. In most cases, you can not be sure of the length of the incoming data. If the data's length exceeds the allowable length, portions of it may be truncated. A second problem is that the URLs passed to the server are logged, and any information tacked onto the URL will also end up in the world readable access log.
<- Back to Index