Figure 1: Browser/Server Interaction.
URL of this paper: http://www.its.unimelb.edu.au:801/papers/AW04-04/
Martin Gleeson,
Information Technology Services,
The University of Melbourne [HREF 1]
Phone: +61 3 344 7407 Fax: +61 3 347 4803
Email:
gleeson@unimelb.edu.au
Home Page: Marty's Makatoa [HREF 2]
Tina Westaway,
Information Technology Services,
The University of Melbourne [HREF 1]
Phone: +61 3 344 4875 Fax: +61 3 347 4803
Email:
tina@www.unimelb.edu.au
Users quickly become familiar with browsing - passively navigating static information albeit in context-sensitive, associative ways. However, using the WWW for interactive applications necessitates the use of the Common Gateway Interface (CGI). The CGI/HTML form interface allows for the submission of data to a server, which can then be manipulated in a variety of ways. The authors will provide examples of these uses such as: addition and modification of records to a database, electronic mail of data, providing an interface to searching facilities, and a number of other uses. This paper will describe in non-programming terms the architecture which enables interactivity in Web applications. The authors will also explore the implications of developing CGI scripts to enable the use of these interactive applications, as well as methods to create the illusion of state in a stateless protocol (HTTP).
Keywords: World Wide Web (WWW, W3), HTML forms, CGI programs, gateway.
The data entered into an HTML form by a user is assembled by the browser into a series of name/value pairs, a name for each input element, such as a text-entry field, pop-up menu, or checkbox selection, and a value associated with the data entered, or the choice made by the user.
These name/value pairs are then sent to the server to be acted upon by a CGI Program, which is specified by the ACTION attribute of the FORM element in the HTML page that contains the form.
The CGI Program can then act upon the input, and perform a variety of tasks, such as sending an email message, querying or updating a database, or any task able to be performed by a program on the server itself. Examples of these CGI Programs and the forms that provide an interface to them are provided.
Figure 1: Browser/Server Interaction.
Fill-out forms are used in HTML documents to submit information to a CGI program via an HTTP server. Forms can contain a number of elements, some essential, and others optional, depending on the purpose of the form. Any HTML page can be a form, or have a form as an element within the page.
The information below is based on the HTML 2.0 Specification. A List of all Elements in the HTML 2.0 DTD [HREF 3] is available.
The FORM HTML element is used to delimit a data input form within the HTML document, therefore the HTML tags used to collect the input data must be contained within the <FORM> ... </FORM> tags.
The main attributes of the FORM tag are ACTION and METHOD. ACTION indicates the URL of the CGI program to which the HTTP server will pass the input data, and the METHOD attribute selects the variation of the protocol to be used - usually GET or POST, but there are other methods (HEAD, PUT, POST, DELETE, LINK and UNLINK), which are detailed in The Internet Draft of the HTTP/1.0 Specification [HREF 4].
The other elements used in a form are:
Examples showing the rendering of these HTML markup elements.
An HTML Form can reside anywhere within an HTML document, or even be created from within a CGI script (mentioned in the Summary of CGI Operation). The actual form itself is composed from the elements within the <FORM> ... </FORM> tags:
The Common Gateway Interface, or CGI, is a standard for external gateway programs to interface with information servers. Gateways are programs, or scripts which handle information requests and return the appropriate document or generate a document on the fly.
The scripts can be written in languages such as C, Perl, TCL, shell scripts or platform-specific languages such as AppleScript or Visual Basic. It should also be noted that because they are programs, information providers intending to have CGI scripts performing anything more than basic functions should invest in the services of a programmer.
NCSA have published detailed information about the Common Gateway Interface [HREF 5]. The information discussed below is based on the NCSA CGI specification, and so will not go into as much detail as the specification. Readers interested in creating CGI programs are encouraged to read the CGI specification in full.
The most useful source of information for CGI programmers is the CGI Programmer's Reference [HREF 6], which contains a Frequently Asked Questions list, language-specific resources for CGI programmers, pointers to CGI documentation, browser peculiarities and more.
The server passes the data submitted by an HTML form to a CGI program by environment variables and/or standard input. The CGI program then executes and should return some information to the user regarding the success or failure of the tasks that it is expected to perform. Some of the more relevant environment variables are detailed below:
Note that the difference between the two main methods used for sending user input to the CGI program, GET and POST, is that the user input for GET is appended after the "?" in the URL of the CGI program, subjecting it to the limit of 256 characters in a URL. Conversely, POST sends the user input to the CGI program as standard input, and so is not subjected to any (known) limit - browser or server bugs notwithstanding.
This example shows an HTML form containing a simple substring search of a database of email addresses.
The HTML Form: the search form itself, and
a version showing the HTML elements.
The Perl CGI Program.
The database is a simple flat file, with five tab-separated fields of name, organisation, email address, paper number and paper title. The program accepts the search term from the name/value pair in the URL. Each line that matches the search term is displayed in the HTML page returned by the CGI program, with the email address turned into a "mailto" URL and wrapped in a hypertext reference, to the users of mailto-capable WWW browser software can simply select the email address to send a message to the user.
This example shows an HTML form with the CGI program sending the data to a third party via email.
The HTML Form: the Form itself, and a
version showing the HTML elements.
The Perl CGI Program.
The example of the forms interface used here is a requisition for approval for purchase of computer equipment.
The Perl CGI program processes the values input from the form, according to their variable names. The information is validated and if acceptable is emailed to the appropriate person. If it is acceptable the information is displayed on the screen for hard copy print out. If it is not acceptable, i.e. mandatory fields are missing or the email address is not normal, then a rejection message is displayed explaining why the data is unacceptable.
As well as the email action, the data can be passed to a script to update the database of applications. This has yet to be implemented.
The Common Gateway interface describes methods for interaction between information servers and external gateway applications (or, in general, any external applications). The email gateway example shown illustrates the interaction between the CGI program and an email gateway. Both examples also show that CGI programs can build HTML pages to return to the user's WWW browser, suggesting that CGI programs can be used to build a collection of dynamically constructed HTML pages.
Figure 2: CGI/Server Interaction
The information systems of the past decade have typically consisted of a front-end user interface and a back-end server which manages data. The front-end is usually a terminal emulation program run on a PC and is a character based interface. The back-end computer has control of data management and presentation as well as the user interaction. This is referred to as a dialog-service.
These dialog-service systems are stateful (see below for definition of state). By this we mean that the server can be in different states and the response of the server to a request depends on previous commands.
More recent information systems are based on the client-server paradigm, where the clients handle presentation and user interaction and servers manage the data. These clients can have graphic or text based interfaces and are server independent.
This model is best suited for Internet communications as information can be provided on many servers. The information retrieval for this type of service needs to be fast and stateless protocols have been designed for this purpose. By stateless protocol we mean that the server response depends only on the commands it is given.
[Comer et al. 94] defines: "Information that a server maintains about the status of ongoing interactions with clients is called state information. Servers that do not keep any state information are called stateless servers; others are called stateful servers". State information includes all stored state variables and their values. An individual set of values defines a state. A server is said to change its state whenever the values of its state variables change.
Hypertext Transfer Protocol (HTTP) is based on a client-server model which uses a stateless protocol. As such, browsers provide the user with a static page. Whilst the user can click on links and have information downloaded the interaction with the server is not dynamically related. Browsers employing this stateless protocol cannot directly engage in ongoing interactivity with stateful servers.
An example of an interactive session simulation between a stateful server and a stateless client would be playing a game of Othello [HREF 7] through a W3 browser . You play the server through the browser interface and the board positions are recalled and reconstructed each time you contact the server.
The information has to be stored somewhere or passed back an forth each time a move is made. For most applications the method of passing the information back and forth is the most reliable. This avoids the problem of cache presenting a false image of the states. The disadvantages are use computing power to recreate the situation, network traffic is increased and the plot will be lost if the connection is broken for any reason.
Several methods have been purported to address this issue [ Perrochon 94b]. One is to define special "document"-types for stateful services. The browser treats them like other documents, but they need to be handled by an external program. Another method is to employ a Translation Server to process the HTTP requests from the front-end and transform them into dialog-type communicationwith the back-end. The results are translated by the information server into HTML and returned like any other W3-object.
The CGI interface is a good candidate for such an intervention layer.The information request can be entered via the HTTP¹s forms, passed to the external program and returned to the user as HTML.
The issues of state information can be handed back and forth via the name/value pairs of the forms and hidden from the user by utilising HTML's HIDDEN fields and PATH_INFO environment variable. The email address can also be used for unique user identification.
The problem of entering and updating data using stateless browsers is, as yet unresolved. Usually, this process is transaction based on stateful servers and this is how record/file locking, access security and data validation are controlled. Dynamic state information and business rules need to be handled by the Translation Server. But these servers should not be application specific. Otherwise they have to be re-engineered whenever the stateful server interface changes . Therefore they need to be generic tools that service a multitude of services and interpret the schema (the interaction protocol used when accessing a dialog service) from the stateful server. When the dialog service changes the schema need to be recompiled and the Translation Server should not be affected.
There is also the ever present issue of charging for services. This is also the case with proxy servers. This may be resolved by extensions to the HTTP protocol.
HTTP servers supporting CGI which can spawn external programs to compute results which the server returns to the browser can be used to develop the sort of interactivity required to interface to older stateful systems. This can be a cost effective way to utilize the information of established systems whilst giving platform independence and a comtemporary interface.
