In Chapter 8, we introduced you to some of the problems of working with
multiple forms, and presented a few possible solutions. In this chapter,
we approach the problem again, using our new familiarity with clients
and servers.
An interface consisting of multiple forms presents thorny
problems for CGI. How do you remember the information stored on
different forms? A normal graphical interface application (running
on a local machine) simply displays forms and stores results, as
shown in Figure 10.4.
It is easy to store information from successive forms when
a client and a server are not involved. But when you use CGI, the
server invokes the program repeatedly each time a form is submitted.
Instead of a single running program, you have multiple instances,
as shown in Figure 10.5.
The problem you face is how to tell each instance of the program
what data was retrieved by the previous runs.
Temporary files are a simple solution, but a messy one. The
program has to know which file to read and write each time. Knowing
the right file is complicated when multiple users are running the
program at the same time. Furthermore, the information is not very
secure, because the files are visible on the system. The time required
to access the files can slow down the operation. Finally, you have
to remember to clean up the files, when the user goes away and does
not finish the session.
A much more elegant solution involves a special server whose
job is to maintain state for CGI programs. This server runs continuously,
like any other server. CGI programs of all types and purposes can
use this server to store information. The big advantage that a server
has over temporary files is that the data remains in memory. This
makes operations faster and keeps the data much more secure.
The heart of the server approach is that a CGI program knows
how to retrieve data that a previous instance of the program sent
to the server. Each instance of the program needs a kind of handle
so it can find the data. To furnish this access, the server associates
a unique identifier with each user who runs the CGI program. The
program supplies the identifier when it stores the data, and another
instance of the program supplies the identifier again to retrieve
the data. Given to colorful language, computer people like to call
such identifiers "magic cookies." Using a single cookie, a CGI program
can keep track of any amount of data. So the server is called a
cookie server, while the CGI program is called the cookie client.
Another major problem has to be solved to use cookies. One
instance of the CGI program has to pass the cookie to the next instance.
If you look at Figure 10.5, you may see the solution in the arrows:
Pass the cookie to the next form, and have the form pass it back.
This is the solution we will use in this book. When the CGI program
builds each form, it embeds the cookie in a hidden field. When the
user submits the form, it passes back the hidden field. The new
instance of the program, when it starts up, can retrieve the cookie
like any other field, and ask the server for the data. The procedure
is shown in Figure 10.6.
Let's trace a cookie, and the data associated with it, through
a complete session.
- The user fills out the first form,
and the CGI program is invoked for the first time.
- The CGI program contacts the server for the first
time. The server creates a cookie and passes it to the program.
The program also passes data to the server, using the cookie given
to it by the server.
- The program creates the next form for the user,
embeds the cookie in a hidden field, and sends the form to the browser.
- The browser displays the form, which is filled out
by the user and submitted. The form passes back the hidden field
with the cookie.
- A new instance of the CGI program begins. It gets
the cookie from the form data, and starts contacting the server
all over again. This time, the program passes the existing cookie
instead of creating a new one.
This is our strategy. Understanding this, you should not have
much trouble following the code that is about to follow.
![[Graphic: Figure 10-4]](./figs/cgi1004.gif)
![[Graphic: Figure 10-5]](./figs/cgi1005.gif)
![[Graphic: Figure 10-6]](./figs/cgi1006.gif)
