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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Petros Koutoupis' RapidDisk
- ServersCheck's Thermal Imaging Camera Sensor
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Varnish Software's Varnish Massive Storage Engine
- Firefox 46.0 Released
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide