As web developers, we all learn that sessions help overcome the problems related to the stateless nature of HTTP. We create a unique session id, and send it to the browser -- and when the browser sends the same id back to us, we identify the user easily.

All this sounds pretty straightforward, and NOT so complicated to implement in any language.


Look at the following screenshots I took. These show the kinds of cookies popular websites store. It looks like they are storing multiple session IDs, or they are trying the hide the actual id by setting so many cookies, or, it is something very specialized security measures they're taking to prevent session hijacking and other related problems. Or, whatever.

Gmail (before login)

enter image description here

Gmail (after login)

enter image description here


enter image description here


enter image description here

(Don't worry, you can't steal my session -- it's stale and incomplete :))

So, my question is -- what purpose does this complicatedness serve? Please explain what these different cookies mean (in general), and for what purposes these are set. Lastly, hint on how I can do it (and whether I should) in my own apps.

One more question: In a lot of instances, the values in the cookies look like they are URL-encoded -- why so?

1 Answer 1

  1. Sometimes it's not practical to store certain data in a session table on the database. If certain data gets updated a lot then it could bog down the database a lot as well. If that's the case and the data's not too important, it might be better stored in a separate cookie.

  2. When (1) happens you have to deal with the 4kb-per-cookie limit, so storing all of the in-cookie session data in one cookie is a bad idea.

  3. It'd be nice to be able to store everything in the minimum number of cookies required, but project complexity concerns make this difficult. Some applications are developed by several teams. Sometimes what you see as one web server is actually a proxy that talks to several different clusters of web servers, routing different sections of the site to different clusters, each with their own set of cookies.

  4. Cookies are cheap. You're the exception to the rule - nobody looks in their cookie store to see how many cookies they have. And there is little performance benefit to trying to combine all of the client-side session data into as few cookies as possible.

  • I'm also the exception to the rule. May 1, 2012 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.