Cookie Monsters
By Randal L. Schwartz
Ahh, cookies. One of my pet peeves is the amount of bad cookie code I see out there—like the code responsible for the reaction I get from a Web site when I choose not to permit cookies (usually because I'm feeling rebellious). Cookies are one of many ways to turn stateless HTTP into a series of session-based transactions with states like "logged in" and "logged out." Other ways to achieve a similar transformation of HTTP include using authentication, mangling the URLs, and hiding data.
Cookies are the object of my ire because so many Internet programmers assume that "one user equals one Web browser." After all, that's the basic model of the cookie itself. But that assumption is also demonstrably untrue. For example, right now I have three browsers open. And, I've been known to enter an Internet café from time to time and use the browsers it supplies. The problem is that when I move from browser to browser, my cookies don't follow me.
Bad Batches
What are the wrong ways to use cookies? Let me count them: One is to use cookies with a login form that, upon successful login, sends out a cookie that lasts for several years. That cookie works only for the particular browser I used when I filled out the login form. Because of this, I can't log in using a different browser unless I fill out the login form again. Worse yet, if I'm using an Internet café's browser and I forget to log out, the next user who stumbles across that Web site is already logged in as me.
Then there are Web sites that send out a bunch of data inside a cookie, such as the entire contents of my shopping cart.
