A Pain-Free Introduction to Building Interactive Web Sites
This is the Title of the Book, eMatter Edition
Copyright © 2004 O’Reilly & Associates, Inc. All rights reserved.
Remembering Users with Cookies
A web server is a lot like a clerk at a busy deli full of pushy customers. The custom-
ers at the deli shout requests: “I want a half pound of corned beef!” and “Give me a
pound of pastrami, sliced thin!” The clerk scurries around slicing and wrapping to
satisfy the requests. Web clients electronically shout requests (“Give me /catalog/yak.
php!” or “Here’s a form submission for you!”), and the server, with the PHP inter-
preter’s help, electronically scurries around constructing responses to satisfy the
The clerk has an advantage that the web server doesn’t, though: a memory. She natu-
rally ties together all the requests that come from a particular customer. The PHP
interpreter and the web server can’t do that without some extra steps. That’s where
cookies come in.
A cookie identifies a particular web client to the web server and to the PHP inter-
preter. Each time a web client makes a request, it sends the cookie along with the
request. The interpreter reads the cookie and figures out that a particular request is
coming from the same web client that made previous requests, which were accompa-
nied by the same cookie.
If deli customers were faced with a memory-deprived clerk, they’d have to adopt the
same strategy. Their requests for service would look like this:
"I'm customer 56 and I want a half-pound of corned beef."
"I'm customer 29 and I want three knishes."
"I'm customer 56 and I want two pounds of pastrami."
"I'm customer 77 and I'm returning this rye bread -- it's stale."
"I'm customer 29 and I want a salami."
The “I’m customer so-and-so” part of the requests is the cookie. It gives the clerk
what she needs to be able to link a particular customer’s requests together.
A cookie has a name (such as “customer”) and a value (such as “77