Cookies, Sweet and Sour
By Lincoln D. Stein
Cookies. To some, they're Web treats, enriching our Web-surfing experience with customized pages, shopping carts, and smart pages that welcome us back on repeat visits. To others, they're the storm troopers of the Web, part of a multinational conspiracy to tear away our last shreds of privacy and reduce us all to entries in some market researcher's database. What are they really?
Cookies are an attempt to get around one limitation of the HTTP protocol. HTTP was designed to be efficient for fetching many small documents from servers scattered all over the place. As a result, its designers made it stateless. A browser connects to a server, fetches the document pointed to be a URL, and closes the connection. The next time the browser needs to fetch a document from the same server, it opens up an entirely new connection and repeats the process from scratch. Although from the user's point of view the sequence of connecting to a site's welcome page and browsing through its pages is a continuous stream of events, the server sees it only as a discontinuous series of requests for URLs. Each request for a document, even if it's an embedded graphic within an HTML page retrieved just a second ago, is treated as a whole new request.
While this stateless behavior reduces the HTTP protocol's overhead, it causes headaches for Web authors who want to do more than create a set of static HTML pages. Consider the problem of creating a Web interface to a database. In a typical database application, you establish a connection to the database software, authenticate yourself, pose a query, view the result, refine the query until you're satisfied, then generate a summary report.
