HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

State Preservation by Hidden Elements

There are two ways to use TYPE=“hidden” INPUT (“hidden,” for short) elements to preserve state information. First, the gateway program can place all the data received from the client inside “hidden” elements returned with the FORM used for the next stage of a transaction. Then, the subsequent access to a server resends the data from the previous interaction(s), since all the data are preserved in the “hidden” elements. The second method is to create a temporary file on the server and store the transaction data within this file. In this case, the gateway program need only return a single “hidden” element containing the name of this temporary file, so that the gateway program, on subsequent requests, is told where to find the state information. This reduces the amount of data that must be sent from client to server (and back again), but also means that the gateway programs must carefully manage these temporary files. For example, many remote users may not complete the transaction, which will leave temporary files in place unless there are auxiliary routines for deleting “stale” entries.

State Preservation by Netscape Cookies

The “hidden” form element mechanism works, but is not ideal. Problems arise if a user does not move through the sequence exactly as planned and in a single session. For example, a user might get halfway through a process, shut off his or her computer and go home, hoping to resume the next morning. This is not possible with “hidden” form elements, since all the state information is lost when the browser is turned off.

As a partial solution to this problem, Netscape introduced a mechanism commonly known as Netscape cookies. The idea behind cookies is to have the browser store, on its local hard disk, specific state information sent by the server. In a sense, this is like storing “hidden” element data, but outside the document and in such a way that they can be retrieved whenever needed. The cookie content is then sent to the server, as part of the HTTP request header, when appropriate.

Cookies are sent to a browser using a Set-Cookie HTTP response header field or fields (the server can send multiple cookies in a single transaction). In turn, the browser sends cookies to a server using a Cookie HTTP request header field.

Putting a Cookie on the Browser

An HTTP server places cookie information on a browser by sending a special Set-Cookie HTTP response header field—which is often returned by CGI programs within a server directive. The Set-Cookie field contains the cookie content as a name/value pair and can also contain information explaining when the cookie will no longer be valid (expires), the Internet domain for which the cookie is valid (domain), and the path portion of the URL within this domain for which the cookie is valid (path).

Cookie Parameter Values

The general form of a Set-Cookie header field is:

Set-Cookie:  name=value; expires= date; path= val_path; domain= dom_nam; secure

Note that the different parts of the cookie header are separated by semicolons. Most of these parameters are optional. The meanings and uses of the parameters are described in Table 10.4.

---

TIP: No Quotation Marks in Parameter Fields

Unlike HTML attributes, cookie parameter values must not be enclosed in quotation marks. Thus, you must type domain=.sub.domain.edu and not domain=“.sub.domain.edu”—the latter will not work. Similarly, you must not surround the name=value portion with quotes, as the quotation marks will be taken as the first character of the name and the last character of the value.

---