I am learning about cookies, and I wonder about browser support when writing web applications that rely on cookies to store state.
For each domain/web site,
Different browswers have different size limites on cookies. Here is the information for IE. Here is a page that lists several browsers.
Cookies are not saved on a server basis but on a domain basis (a server may host many domains or the opposite a server farm may be serving a single domain).
In general, I would avoid saving lots of information in cookies, as the data gets sent to and from the browser on every request. As you suggest in your question, this can have a effect on performance.
Usually one stores small amounts of data in the cookie, mostly used to identify the user/session so more data can be picked up from a database or another resource local to the web server.
Here's a really good site on cookie limits and lets you test your browser:
http://browsercookielimits.iain.guru/
Cookie Size Limits
If you want to support most browsers, then do not exceed 50 cookies per domain, and 4093 bytes per domain. That is, the size of all cookies should not exceed 4093 bytes.
Performance Thoughts
Cookies are sent on every request for a domain, this includes images. For arguments sake, lets say you have 30 resource on your website, and have 4093 bytes of cookies. That means the user is uploading 122Kb of data. So if I have a 1Mbit upload connection, that will take at least 1 second.
If you want to see the cookie test page I created, or read more about it check out Browser Cookie Limits.
If you are concerned about performance decreases due to large cookies being sent on each server request, a good idea might be to place all your static files (images, CSS, etc.) into a subdomain of your site, like http://static.yourdomain.com
.
In this way, whenever your site on www.yourdomain.com
asks for a static file,like an image, the browser won't send the cookie along with the HTTP request anymore.
Source: http://developer.yahoo.com/performance/rules.html#cookie_free
Firstly, I suggest you don't worry about this issue. There is AMPLE room to serialize tons of identifiers to.
Secondly it's not stored by web-server
but by web-domain
— e.g., www.google.com
and not the 100's of different physical servers that serve the Google domain.
Thirdly if you do have to worry know that there are two possible cookie headers. The sizes of these cookie headers are determined by the browser software limits.
Design Discussion
What you don't want to use the cookie header for is sending details about a client's session. E.g., don't try to stuff the email a client is typing into a cookie if you are building an email front-end. Instead you would send the client a cookie that represents his identity+session: you store all sessions data against this identity. You can store tens of identifiers (4–16 bytes) per cookie header and no one needs more than say 4 of these. The cookies data (as an integer) tends to be encoded to base64 which increases the byte-count.
Performance
Your browser sends a plethora of headers to a web-server. The cookie is just another 100-1000 bytes (mostly closer to 100). At both extremes it takes only a fraction of time to send these to the web-server — when placed into context of course. You should keep in mind that the web is built on text based protocols.
4096 bytes The real problem, however, comes when you try and set cookies with a large size. The standards state that a browser must support a minimum of 4096 bytes per cookie. IE6 doesn't do this. Instead, it seems to have a maximum size of 4096 bytes for all cookies from a domain.