views:

214

answers:

3

We are facing an issue where the following check fails intermittently in IE:

pseudocode:

setCookie("name","value", "1d");
if(getCookie("name") === "value"){ 
  return SUCCESS;
} else {
  return FAILURE;
}

this little routine checks if the user has cookies enabled. it shouldnt fail but it does. is it because IE can only handle a certain amount of cookies? (we set lots of cookies).

is there some other way to do a cookie check that is more reliable?

+2  A: 

Yes, IE has a preset cookie limit per host. After that the program begins discarding cookies. Check here for more info...

I'd recommend you use use cookies only to track the userid, for everything else you should use something like "Session State".

do you know of a workaround for this issue?
mkoryak
Like I said, you should store your user data on the server. For instance, you can use "Session State", "View State" or in more extreme cases just write to a database.
+1  A: 

As bastos.sergio said, use session.

That said, if you have load balanced web servers, ignore session and pull the data straight from the database server when you need it.

If it is a single web server, then use session.

Regardless, take a look at the data you are storing. ALL cookies for a domain are sent back on every web request. All session data is also loaded up for every single web request.

If you don't need the data for every web page, then you shouldn't cache it in cookies or session as it actually causes a greater performance penalty than just pulling it when you need to.

This is why the only things that are typically stored in cookies or session are simple items like the user id.

Also, I believe IE limits the site to 20 separate cookies for a total of 4KB of data.
See http://support.microsoft.com/kb/306070

UPDATE: Scratch the limit of 20. IE 5,6, and 7 support up to 50 cookies provided a particular update from August 2007 was applied. http://support.microsoft.com/kb/941495 However, the 4KB limit is still imposed.

And see this blog entry which covers exactly why large amounts of cookies are a bad idea.

Chris Lively
A: 

is it because IE can only handle a certain amount of cookies?

Could be, but that limit is quite high — way more than you should be setting in practice. Don't put large amounts of data in cookies; they are sent on every HTTP request, slowing your application down. On IE you can store larger amounts of data in userData, and on newer browsers you can use DOM Storage, either way without the HTTP overhead. But relying on these isn't brilliant for compatibility. Do you really need to store that much on the client side? For a general-purpose web app this may be a sign that you are Doing It Wrong.

is there some other way to do a cookie check that is more reliable?

No, that's pretty much it. Note that you can fail to set the cookies-with-expires-date but succeed to set a session cookie (no expires date; expires when the browser is closed). This is because in IE when you block persistant cookies they are completely blocked, not downgraded to session cookies as on some other browsers. So for some purposes you need two checks.

bobince