HTML Forms: Interacting with the Net
SELECT is the next major markup tag. The SELECT tag is used to encapsulate a selection list. Several <OPTION> tags may be included between a <SELECT> and a </SELECT>, to add elements to the list. A selection list may take on two physical forms. If it has a SIZE of one, it appears as a popup menu. If the SIZE attribute is greater than one, it appears as a scrollable list displaying SIZE options one at a time. Here are the possible attributes of the SELECT tag:
Indicates a symbolic name for the selection menu.
The physical number of lines that are visible at any time.
If this attribute is present, multiple items of the list may be selected at one time.
These attributes are straightforward, and I'll leave them for your exploration later. Before we move on, I should mention a little more about the <OPTION> tag. The option tag can have the attribute SELECTED. When present, this attribute indicates that a particular list item is selected by default. The <OPTION> tag is much like the <li> of normal HTML lists; it does not require a terminating </OPTION> tag. Instead, the appearance of an <OPTION> tag indicates the beginning of a new list item and the termination of any preceding items. Also, a selection list item can be only simple text. List items cannot be marked up, nor can they be anchored items.
A form element where a user can type in free-form text, much like entering text into an editor, is constructed using the TEXTAREA tag. A text entry area is has the basic form of:
The default text is the initial text, if any, which is present in the text entry area. This form element has three easy-to-use attributes.
Indicates a symbolic name for the selection menu.
The vertical size of the text entry area.
The horizontal size of the text entry area.
Now that we know what things we have available, let's create a basic form. Listing 1 shows a simple HTML form, while Figure 1(139K) displays how Mosaic might present this form.
Keep in mind that the ACTION attribute needs to specify your host and a valid script or program. In the example, the shell script echo.sh (shown later) will be executed on your.http.host when the form is submitted. The script or program needs to reside in a directory which your server recognizes as a valid location for executable programs. Be sure to check the documentation for your server to be sure it is configured properly to allow for this sort of execution. A typical location for these sorts of programs is in the cgi-bin directory under the server root, and that is how this example is configured.
The form is only one of the three parts necessary to interact with a user. The second is the http server, which we will not cover here (please refer to the documentation for your server). The third is a CGI program or script. As mentioned above, these programs must reside in a directory recognized by the http server as a valid location for executables. A CGI program needs to be able to understand the encoded form data as it is returned from a client, and must be able to respond appropriately. The encoded form data will appear either on the command line or in the environment variable QUERY_STRING, depending on whether a METHOD of GET or POST is used. Typically, a program needs only write the necessary response on stdout, and the response will then be transmitted back to the client by the http daemon.
A number of environment variables are also typically set by the server for the CGI program's use. Following is a partial list of environment variables that I find useful. Please refer to hoohoo.ncsa.uiuc.edu/cgi/env.html for further discussion of other environment variables.
Set to the METHOD used to make the request.
Set to the encoded form data when the GET METHOD is used.
Set to the remote hostname if available.
Set to the IP address of the remote host.
The length of the data returned in a client's query.
Usually, a CGI program need only respond to a request with an appropriate http header, possibly followed by a document. The response is simply written on stdout, where the data will be returned to the client. A header consists of an http header directive followed by a relevant text string. The header is terminated by a blank line. Two of the most used header directives are the Content-type and Location directives. The Content-type directive indicates the type of data which is to follow. For example, Content-type: text/html indicates that the document which follows the header on stdout is written in HTML. The Location directive is used to provide a means by which redirection can take place. For instance, Location: http://goto.another.host/web/doc.html would cause a client to retrieve the document specified in the URL.
Probably the easiest way to explore the construction of a CGI program is with an example. Listing 2 shows a shell script which will respond to a client's HTML form request.
The response is to echo the encoded query, some of the environment variables, and the decoded content of the query. This program is useful as a test program when creating new forms, and as a base for building other CGI scripts. Figure 2(135K) displays the results of posting the form shown in Figure 1 to this script.
Examine the QUERY_STRING in Figure 2 Notice that spaces are encoded as addition signs, and that an ampersand in the input is encoded as a hex value preceded by a percent sign. Also notice that each name/value pair is separated by an ampersand. The shell script decodes this string back into the data as it was entered by the user. There are other programs, such as CERN's cgiparse, which will also help you decode CGI form data.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
|Non-Linux FOSS: .NET?||Apr 13, 2015|
|Designing Foils with XFLR5||Apr 08, 2015|
|diff -u: What's New in Kernel Development||Apr 07, 2015|
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Play for Me, Jarvis
- Non-Linux FOSS: .NET?
- Flexible Access Control with Squid Proxy
- New Products
- Not So Dynamic Updates
- Designing Foils with XFLR5
- Users, Permissions and Multitenant Sites
- diff -u: What's New in Kernel Development