Digital Media
Moshell -Spring 98
Lecture 20: Cookies
From S: Chapter 10, pages 290-310
In our Lab 2, we had to maintain the state of the transaction (the information
which was entered in the first screen) by putting it into hidden variables
and sending it back to the client. The project was deliberately designed
to require two screens, to force you to learn how to do this trick. However,
there is another way. You can cause a server to retain the state,
and simply pass back to the client some kind of unique identifier - like
a claim check in a coat-check room (only meaningful if you have lived outside
of Florida!)
In the textbook example, rather than using one's own CGI script and
reading and writing to a database, a separate cookie server is used.The
server is really a process (specified by a Perl script) that always runs.
So in effect, it creates a RAM-based temporary database in the form of
an associative array.
Query 20.1: What are some of the advantages and disadvantages
of this RAM-based cookie store, versus a truly persistent disk-stored database?
There are two approaches described in the book: "temporary cookies"
which are handled via hidden variables in the forms being sent to individual
customers; and "Netscape persistent cookies" which are handled by Netscape
Navigator itself (and also by Internet Explorer, copy-cat style.)
Temporary Cookies: The essential story is this:
-
When a user initially reuqests a page, the cookie server generates a unique
random number (the cookie key) and provides it to the CGI script. This
is then sent out as a marker along with each of the successive forms which
the client requests. As the form data comes back in, it is stored in the
Cookie Server, using the cookie key as a handle.
-
When the CGI script is ready to summarize the order and put it into permanent
storage, it asks the cookie server for all the data. At this point the
CS deletes its records for this key.
In this first figure, we can see the story being told.
Netscape Persistent Cookies: The essential story here:
-
When a client first contacts the CGI script, it checks an environmental
variable to see if that client already has a cookie from this business
("Super_Sales.com"). If not, a new one is generated. If so, the system
knows we're dealing with a returning customer.
-
If a new cookie is being generated, it is provided to the client for storage
in Netscape Navigator's persistent cache.
-
The rest of the transaction continues as above, except that the CGI script
can now fetch permanent data from the cookie server if needed (e. g. the
customer's credit rating.)
-
At the end, the cookie server can update its permanent data about this
customer (that is, the hash table has a database component to it. Thus
when the CPU crashes or the cookie server is restarted, the customer's
data is not lost.
-
The order is stored in the order database (separate from the cookie-facts)
as usual.
And here is that elaborate story, in picture form:
Query 20.2: Is there anything that the Netscape Persistent Cookie
system can do, (in terms of helping your business to grow and prosper and
make money) which the temporary cookie technique cannot do?
Query 20.3: Could you add the persistent cookie-server database
concept to the Temporary Cookie scenario? What would be the advantages,
or disadvantages of doing such a thing?