Cookie is set twice; how to remove the duplicate? - javascript
So I have a website that uses a cookie to remember the current layout state across visits. Everything was working great until I added a Facebook 'Like' button to the site which generates links that allow users to share a certain UI state (a little confusing but not really relevant to the problem).
The problem is that when I visit the site via one of these Facebook links a second copy of my layout cookie seems to be created (as in, I see two cookies with the same name and different values). This wouldn't be too terrible except that the value of the duplicate cookie appears to be stuck, coupled with the fact that when the user returns to the site the browser remembers the stuck value instead of the most recently set value (so it's kind of like there's a "good" cookie that I can still work with, and a "bad" one which I cannot, and the browser likes to remember the "bad" cookie instead of the "good" cookie). This breaks my layout tracking/remembering functionality.
So there are two questions here:
How do I stop this from happening/why is this happening in the first place?
How do I fix things for any users that already have a stuck cookie (I know I could just pick a new name for the cookie, but I'd rather do it by finding a way to properly unstick the stuck cookie)?
If I use Chrome's developer console after visiting the page in a stuck state, I can see that document.cookie is (formatting added for readability):
layoutState=[{'id':6,'x':8,'y':1525,'z':4,'url':'undefined'}, {'id':1,'x':625,'y':709,'z':2,'url':'undefined'}, {'id':2,'x':8,'y':37,'z':3,'url':'undefined'}, {'id':3,'x':625,'y':1179,'z':5,'url':'undefined'}, {'id':4,'x':626,'y':37,'z':1,'url':'undefined'}, {'id':5,'x':626,'y':357,'z':1000000,'url':'http://m.xkcd.com/303/'}];
WibiyaNotification1=1;
WibiyaNotification213286=213286;
WibiyaNotification213289=213289; wibiya756904_unique_user=1;
JSESSIONID=DONTHIJACKMEPLEASE;
WibiyaProfile={"toolbar":{"stat":"Max"},"apps":{"openApps":{}},"connectUserNetworks":[null,null,null,null,null,null]};
WibiyaLoads=59;
layoutState=[{'id':6,'x':8,'y':1525,'z':4,'url':'undefined'}, {'id':1,'x':625,'y':709,'z':2,'url':'undefined'}, {'id':2,'x':8,'y':37,'z':3,'url':'undefined'}, {'id':3,'x':625,'y':1179,'z':5,'url':'undefined'}, {'id':4,'x':626,'y':37,'z':1,'url':'undefined'}, {'id':5,'x':626,'y':357,'z':6,'url':'http://m.xkcd.com/303/'}]"
Ignore the Wibiya cookies and the JSESSIONID. The stuck cookie is the first 'layoutState' instance, and the one that I can still manipulate in JavaScript is the second 'layoutState' instance. Here is what I get if I change some things around:
layoutState=[{'id':6,'x':8,'y':1525,'z':4,'url':'undefined'}, {'id':1,'x':625,'y':709,'z':2,'url':'undefined'}, {'id':2,'x':8,'y':37,'z':3,'url':'undefined'}, {'id':3,'x':625,'y':1179,'z':5,'url':'undefined'}, {'id':4,'x':626,'y':37,'z':1,'url':'undefined'}, {'id':5,'x':626,'y':357,'z':1000000,'url':'http://m.xkcd.com/303/'}];
WibiyaNotification1=1;
WibiyaNotification213286=213286;
WibiyaNotification213289=213289;
wibiya756904_unique_user=1;
JSESSIONID=DONTHIJACKMEPLEASE;
WibiyaProfile={"toolbar":{"stat":"Max"},"apps":{"openApps":{}},"connectUserNetworks":[null,null,null,null,null,null]};
WibiyaLoads=59;
layoutState=[{'id':1,'x':8,'y':39,'z':1000000,'url':'undefined'}]
The second 'layoutState' has the correct information that I want the browser to remember. However what the browser actually remembers is the value of the first instance.
I've tried unsetting the cookie entirely, which causes the second instance to disappear, but nothing I do seems to get rid of the first instance. I get the same behavior in all major browsers (Chrome, Firefox, IE), which makes me suspect that I must be doing something fundamentally wrong here, but I'm not sure what it is.
You can view the site itself here. Or click here to access it via a Facebook link (should generate a stuck cookie). Any help is much appreciated.
Update:
So the steps to reliably reproduce the error are as follows:
Visit the site via the Facebook-style link
Make some changes to the layout, and then close the tab.
Visit the site via the normal URL.
Your layout from the initial visit should be correctly remembered, so change some things around and then refresh the page. When the page reloads, your changes will no longer be remembered.
I've also noticed that revisiting the site via the Facebook-style URL is able to clear/reset the stuck cookie. So it's like the browser is keeping a separate cookie for each URL path, or something, and not allowing the root page to access the cookie that was set on the other URL path. I thought I might be able to fix this by explicitly setting path=/ on the cookie, but no dice.
Update 2:
I've found that if I set both the path and the domain of the cookie I get different behavior in all browsers:
Firefox - Works correctly now, hooray! Worked correctly once, then broke, boo!
Chrome - No change
IE - Seems to be keeping separate cookies for each URL, so the Facebook-style URL remembers one state, and the standard URL remembers a different state. Both update correctly and independently of each other. This is kind of funky, but still way better than the stuck/broken state.
Dude(tte), there are inconsistencies, and a bug, in your cookie setter.
1. Make sure path and domain is correctly set
The path and domain should be the same for both clearing the cookie and setting it. See your code here:
document.cookie = c_name + "=; expires=Fri, 31 Dec 1999 23:59:59 GMT;";
and compare it to:
var c_value=escape(value) + "; expires=" + exdate.toUTCString(); + "; path=/spring; domain=aroth.no-ip.org";
you will see that the setter has both of them, but the deleter doesn't. You will bring about chaos.
2. Oh, and that nasty semicolon
That second line of code I quoted above, has a semicolon introduced in the middle of a string concatenation expression. Right after exdate.toUTCString(). Kill it. Kill it…now.
At least on my Google Chrome, I managed to get it run correctly, if I set a breakpoint at json = "[" + json + "]"; and modify setCookie before it is executed.
P/S: It was a bizzare debugging experience, where I managed to set 4 layoutState cookies, by fiddling with path & domain.
This may be too simple, but just in case, are the cookies recorded for two different paths? If the URL is different, you may be setting your cookies for a restricted path, so the system would take them differently.
Here is a solution, the / slash help to do not set duplicate cookie of same name
setcookie('YourCookieName','yes', time() + 400, '/');
check in Chrome console -> Resources if your page gets loaded twice. That would be the reason of double cookie.
There is again the problem left after identifying the problem and taking prevention by correctly setting the cookie.
You also need to delete previous incorrectly set cookies in your or in your client's browser.
So observe the cookie set from developer tools and search for path and subdomain and put those explicitly on your code to delete.
function eraseCookie(c_name) {
document.cookie = c_name + "=; expires=Fri, 31 Dec 1999 23:59:59 GMT;";
}
function eraseCookieWithPathDomain(c_name) {
document.cookie = c_name + "=; expires=Fri, 31 Dec 1999 23:59:59 GMT;path=/yourpath/to; domain=sub.domain.com";
//you can remove this function call on your second upload if you are confirm that the previous cookie setter expired
}
You may need to call function eraseCookieWithPathDomain right after eraseCookie or even every time after document load depending in your application.
You can add the following key in the AppSettings in the web config file it solves the issue of duplicate cookie.
<!-- Tell ASPNET to avoid duplicate Set-Cookies on the Response Headers-->
<appSettings>
<add key="aspnet:AvoidDuplicatedSetCookie" value="true" />
</appSettings>
This will help avoiding the duplicate Set-Cookie() in Response Headers.
It seems the issue is not a duplicate cookie (cookies overwrite themselves) but a duplication of the DATA in your cookie.
I think you'll have to modify the script that reads the cookie and clean out the duplicate value if it's detected.
Related
Can't remove duplicate cookie
I created a custom UI for the google translate javascript plugin by adding some buttons and then setting the googtrans cookie when the user selects a language. This works totally fine locally. However I noticed when I put it on a live site, the cookie gets set and then a duplicate cookie appears that overrides the one that I've set. Duplicate Cookie The mystery cookie seems to be the domain with a dot prepended to it. I've tried adding the dot to my cookie's domain, but that doesn't work and according to the docs, that dot will be ignored anyway. I've tried just clearing the cookie manually through the Chrome console document.cookie = "googtrans=; expires=" + new Date + "; domain=.domain.org; path=/"; and that does clear the cookie that I set, but leaves the duplicate cookie unchanged. Anyone know a way of nuking all of the possible cookies or something? It's so strange that it only does this on a live site.
Nevermind, I randomly figured it out right after posting this. If I set two cookies, one WITH and domain and one WITHOUT, the one without a domain will write to the .domain.org cookie. document.cookie = "googtrans=;" + new Date + ";path=/;domain=domain.org"; document.cookie = "googtrans=;" + new Date + ";path=/;"; I don't know why, because the documentation says that NOT specifying a domain means that subdomains are NOT included, which is what the dot prefix was originally for.
Can I save a cookie and use it on an other page?
[RESOLVED] I have a little website stored at file:/// with multiple pages with a quiz in each pages. I need to save the results of the quiz in a cookie. When I am changing page, the cookie turn undefined and I don't know how to access the cookie of the previous page. How could I do that ? Is using a cookie the best idea ? Thank you and have a great day. Ben On first page, I put the number 1 in a cookie. When I try to access it on the second page, the cookie is undefined. I would want it to have 1 in it.
No, not directly (because of CORS). But you can: Centralize all cookies (cookiepot.com) When some body visits one of your "share cookie"-sites you redirect him to cookiepot. Cookiepot redirects the user back with the information you need This is how Google+Youtube, Stackoverflow+Stackexchange do it. There is no other way except when servers change the information directly with each other.
EDIT: after the quesion owner edited the question, is was discovered that he used a local file. local files cannot use cookies in most browsers. you can use SessionStorage instead. ORIGINAL ANSWER 2 pages can use the same cookies as long as they are in the same domain. for example, website.com/a.html and website.com/b.html can use the same cookies, but otherwebsite.com/c.html wouldn't be able to use that cookie. are your two pages in the same website? If they aren't, there it is possible to allow one website to use another website's cookies but I have a feeling that's not the case.
Sure you can save a cookie (document.cookie = 'testcookie=;expires=Thu, 01 Jan 1970 00:00:01 GMT;';) and use it on any other page as long as the pages are on the same domain. This is how you save a cookie on a form submit or any other trigger: https://codepen.io/hac/pen/oOKOOe
Overwriting HttpOnly cookie by JavaScript? [duplicate]
Say for example I had an application sending the following HTTP headers to set to cookie named "a": Set-Cookie: a=1;Path=/;Version=1 Set-Cookie: a=2;Path=/example;Version=1 If I access /example on the server both paths are valid, so I have two cookies named "a"! Since the browser doesn't send any path information, the two cookies cannot be distinguished. Cookie: a=2; a=1 How should this case be handled? Pick the first one? Create a list with all cookie values? Or should such a case be considered as a developer's mistake?
The answer referring to an article on SitePoint is not entirely complete. Please see RFC 6265 (to be fair, this RFC was released in 2011 after this question was posted, which supersedes previous RFC 2965 from 2000 and RFC 2109 from 1997). Section 5.4, subsection 2 has this to say: The user agent SHOULD sort the cookie-list in the following order: Cookies with longer paths are listed before cookies with shorter paths. NOTE: Not all user agents sort the cookie-list in this order, but this order reflects common practice when this document was written, and, historically, there have been servers that (erroneously) depended on this order. There is also this little gem in section 4.2.2: ... servers SHOULD NOT rely upon the serialization order. In particular, if the Cookie header contains two cookies with the same name (e.g., that were set with different Path or Domain attributes), servers SHOULD NOT rely upon the order in which these cookies appear in the header. In your example request cookie (Cookie: a=2; a=1) note that the cookie set with the path /example (a=2) has a longer path than the one with the path / (a=1) and so it is sent back to you first in line, which matches the recommendation of the spec. Thus you are more or less correct in your assumption that you could select the first value. Unfortunately the language used in RFCs is extremely specific - the use of the words SHOULD and SHOULD NOT introduce ambiguity in RFCs. These indicate conventions that should be followed, but are not required to be conformant to the spec. While I understand the RFC for this quite well, I haven't done the research to see what real-world clients do; it's possible one or more browsers or other softwares acting as HTTP clients may not send the longest-path cookie (eg: /example) first in the Cookie: header. If you are in a position to control the value of the cookie and you want to make your solution foolproof, you are best off either: using a different cookie name to override in certain paths, such as: Set-cookie: a-global=1;Path=/;Version=1 Set-cookie: a-example=2;Path=/example;Version=1 storing the path you need in the cookie value itself: Set-cookie: a=1&path=/;Path=/;Version=1 Set-cookie: a=2&path=/example;Path=/example;Version=1 Both of these workarounds require additional logic on the server to pick the desired cookie value, by comparing the requested URL against the list of available cookies. It's not too pretty. It's unfortunate the RFC did not have the foresight to require that a longer path completely overrides a cookie with a shorter path (eg: in your example, you would receive Cookie: a=2 only).
From this article on SitePoint: If multiple cookies of the same name match a given request URI, one is chosen by the browser. The more specific the path, the higher the precedence. However precedence based on other attributes, including the domain, is unspecified, and may vary between browsers. This means that if you have set cookies of the same name against “.example.org” and “www.example.org”, you can’t be sure which one will be sent back. Edit: this information from 2010 appears to be outdated, it seems browsers can now send multiple cookies in return, see answer by #Nate below for details
#user2609094 clarifies the behaviour around paths, so I thought I'd add a quick answer for the behaviour around domains (which is unspecified).
If you create cookies for a domain and subdomain ("foo.example.org" and "example.org") with the same name then the browser will send both cookies, with no indication of which one is which. Additionally, the order does not appear to be based on which domain is more specific. From testing in Google Chrome, the cookies are simply sent in the order they were created - so you can't make any assumptions about which one is which.
There is nothing wrong with having multiple values for the same name... if you want them. You might even embed additional context in the value. If you don't, then of course different names are a solution if you want both contexts. The alternative is to send the same cookie name with the same path (and domain) even from the more specific paths. Those set cookie instructions will overwrite the value of that cookie. Now that you know the most important part (how they work), and that you can accomplish what you need in a few different ways, my answer to your question is: this is a developer issue.
I'm certainly aware of applications which do this extensively using multiple session ids - and seem to work consistently. However I don't know - and have no intention of finding out - if they do so because the browser returns the cookies in a consistent order depending on when they were set / which path they were set for or whether the app tries to match each one to an existing session. I would strongly recommend that this practice be avoided. However if you really want to know how the browsers (and apps) handle this scenario, why not build a test rig and try it out.
If you use the Java/Scala framework Play: watch out! If a request contains multiple cookies with the same name, Play will only present 1 of them to your code.
If you need to distinguish them you have to give them different key values.
Same cookie, different values between ColdFusion and JavaScript
I am running into a problem with a cookie I want to access with both JavaScript and CF. I can create the cookie with JavaScript, like so: document.cookie = 'SAVEDLISTINGS='+newc + ';path=/'; and on the next page CF can see it fine. However, if I use the same JavaScript to update the cookie with a new value, CF will not detect the change on subsequent pages. It retains its original value, as evidenced by the debug output and by dumping the Cookie scope. JavaScript continues to see the correct cookie value, which I can check using Firefox developer tools. I assume this means the cookie file is being correctly updated. I do not see two cookies with the same name: only one, and it has the value as manipulated by the JavaScript. I can delete the cookie in JavaScript, using document.cookie = 'SAVEDLISTINGS=; expires=Thu, 01 Jan 1970 00:00:00 UTC' + ';path=/'; and this will delete the cookie from CF as well (on subsequent pages). Note that I am not actually using CFCookie to manage the cookie, but I have experimented with setting it blank by ColdFusion (with httponly=no). This doesn't seem to make any difference.
Set the domain value of the cookie to make sure you are getting/setting the same exact cookie. You can view that info with Firebug. You can see below how two cookies named "testName" are treated as separate entities based on the domain. This is important so different sites can have the same cookie names without overwriting each other.
JavaScript cookie setting used to work and stopped
In a nutshell, I have a web application which used to be able to set cookies just fine, but it no longer works. The really strange thing is I've used Chrome's debugger to follow what's going on, and it makes it all the way to the "document.cookie = " statement fine.
Further, I haven't changed anything except the content of the cookie (adding more information). I haven't modified the cookie setting logic at all, or even the parameters.
Here's the most recent version of my application: http://asmor.com/scripts/tsrand/alpha/
The relevant bit is lines 147-149, http://asmor.com/scripts/tsrand/alpha/init.js
cookie=JSON.stringify(opt)
log("Cookie: "+cookie);
$.cookie(cookieName, cookie, { expires: 365 });
opt is an object I'm using to store form element values. I convert the object into a JSON string and then store it. Here's an example of what cookie contains in this version of the program:
{"diseaseSelect":".5","soloGame":"checkbox:false","showLog":"checkbox:true","min_Setting":"0","max_Setting":"1","cardBarrowsdale":"Maybe","cardDoomgate":"Maybe","cardDragonspire":"Maybe","cardDreadwatch":"Maybe","cardFeaynSwamp":"Maybe","cardGrimhold":"Maybe","cardRegianCove":"Maybe","min_Thunderstone":"1","max_Thunderstone":"1","cardStoneofAgony":"Maybe","cardStoneofAvarice":"Maybe","cardStoneofMystery":"Maybe","cardStoneofScorn":"Maybe","cardStoneofTerror":"Maybe","min_Monster":"3","max_Monster":"3","cardAbyssal":"Maybe","cardAbyssalThunderspawn":"Maybe","cardBanditHumanoid":"Maybe","cardCultistHumanoid":"Maybe","cardDarkEnchanted":"Maybe","cardDoomknightHumanoid":"Maybe","cardDragon":"Maybe","cardElementalFire":"Maybe","cardElementalNature":"Maybe","cardElementalPain":"Maybe","cardEnchanted":"Maybe","cardEvilDruidHumanoid":"Maybe","cardGiant":"Maybe","cardGolem":"Maybe","cardHorde":"Maybe","cardHumanoid":"Maybe","cardHydraDragon":"Maybe","cardOoze":"Maybe","cardOrcHumanoid":"Maybe","cardTheSwarm":"Maybe","cardUndeadDoom":"Maybe","cardUndeadLich":"Maybe","cardUndeadPlague":"Maybe","cardUndeadSpirit":"Maybe","cardUndeadStormwraith":"Maybe","min_Guardian":"0","max_Guardian":"1","cardDarkChampion":"Maybe","cardDeathSentinel":"Maybe","cardGuardianofNight":"Maybe","cardGuardianofTorment":"Maybe","cardUnholyGuardian":"Maybe","min_Trap":"0","max_Trap":"1","cardTrapDeath":"Maybe","cardTrapDire":"Maybe","cardTrapDraconic":"Maybe","min_Treasure":"0","max_Treasure":"1","cardAmuletTreasure":"Maybe","cardFigurineTreasure":"Maybe","cardUlbricksTreasure":"Maybe","min_Hero":"4","max_Hero":"4","cardAmazon":"Maybe","cardBelzur":"Maybe","cardBlind":"Maybe","cardCabal":"Maybe","cardChalice":"Maybe","cardChulian":"Maybe","cardClan":"Maybe","cardDeep":"Maybe","cardDiin":"Maybe","cardDrunari":"Maybe","cardDivine":"Maybe","cardDwarf":"Maybe","cardElf":"Maybe","cardEvoker":"Maybe","cardFeayn":"Maybe","cardFlame":"Maybe","cardGangland":"Maybe","cardGohlen":"Maybe","cardGorinth":"Maybe","cardHalf-Orc":"Maybe","cardLorigg":"Maybe","cardOutlands":"Maybe","cardPhalanx":"Maybe","cardRedblade":"Maybe","cardRegian":"Maybe","cardRunespawn":"Maybe","cardSelurin":"Maybe","cardSidhe":"Maybe","cardSlynn":"Maybe","cardStoneguard":"Maybe","cardTempest":"Maybe","cardTerakian":"Maybe","cardTholis":"Maybe","cardThyrian":"Maybe","cardToryn":"Maybe","cardVerdan":"Maybe","cardVeteran":"Maybe","min_Village":"8","max_Village":"8","cardAmbrosia":"Maybe","cardAmuletofPower":"Maybe","cardArcaneEnergies":"Maybe","cardBanish":"Maybe","cardBarkeep":"Maybe","cardBattleFury":"Maybe","cardBlacksmith":"Maybe","cardBlessedHammer":"Maybe","cardBluefireStaff":"Maybe","cardBorderGuard":"Maybe","cardBurntOffering":"Maybe","cardChieftansDrum":"Maybe","cardClaymore":"Maybe","cardCreepingDeath":"Maybe","cardCursedMace":"Maybe","cardCyclone":"Maybe","cardDivineStaff":"Maybe","cardDoomgateSquire":"Maybe","cardFeast":"Maybe","cardFireball":"Maybe","cardFlamingSword":"Maybe","cardFlaskofOil":"Maybe","cardForesightElixir":"Maybe","cardFortuneTeller":"Maybe","cardFrostBolt":"Maybe","cardFrostGiantAxe":"Maybe","cardGlowberries":"Maybe","cardGoodberries":"Maybe","cardGreedBlade":"Maybe","cardGuardianBlade":"Maybe","cardGuide":"Maybe","cardHatchet":"Maybe","cardIllusoryBlade":"Maybe","cardLantern":"Maybe","cardLightstoneGem":"Maybe","cardMagiStaff":"Maybe","cardMagicMissile":"Maybe","cardMagicalAura":"Maybe","cardPawnbroker":"Maybe","cardPiousChampion":"Maybe","cardPolearm":"Maybe","cardPolymorph":"Maybe","cardQuartermaster":"Maybe","cardRecurveBow":"Maybe","cardSage":"Maybe","cardScout":"Maybe","cardShortBow":"Maybe","cardShortSword":"Maybe","cardSilverstorm":"Maybe","cardSkullbreaker":"Maybe","cardSoulGem":"Maybe","cardSoulJar":"Maybe","cardSpear":"Maybe","cardSpiritBlast":"Maybe","cardSpiritHunter":"Maybe","cardSpoiledFood":"Maybe","cardTavernBrawl":"Maybe","cardTaxCollector":"Maybe","cardThunderRing":"Maybe","cardTorynGauntlet":"Maybe","cardTownGuard":"Maybe","cardTrader":"Maybe","cardTrainer":"Maybe","cardWarhammer":"Maybe"}
Now, here's the oldest backed-up copy I have: http://asmor.com/scripts/tsrand/backup/2010-09-13/dev/
This copy still works.
Here's the cookie-setting logic from that copy, lines 130-132 http://asmor.com/scripts/tsrand/backup/2010-09-13/dev/scripts/init.js
cookie=JSON.stringify(opt)
log("Cookie: "+cookie);
$.cookie(cookieName, cookie, { expires: 365 });
And an example of what the cookie for that one contains:
{"guardianSelect":".5","trapSelect":"1","monstersSelect":"3","heroesSelect":"4","villageSelect":"8","soloGame":"checkbox:false","useConditions":"checkbox:true","showLog":"checkbox:true","setBase":"checkbox:false","setPromo":"checkbox:true","setWrathOfTheElements":"checkbox:false","cardAbyssal":"Maybe","cardDoomknightHumanoid":"Maybe","cardDragon":"Maybe","cardElementalNature":"Maybe","cardElementalPain":"Maybe","cardEnchanted":"Maybe","cardGolem":"Maybe","cardHorde":"Maybe","cardHumanoid":"Maybe","cardOoze":"Maybe","cardUndeadDoom":"Maybe","cardUndeadSpirit":"Maybe","cardDarkChampion":"Maybe","cardDeathSentinel":"Maybe","cardTrapDeath":"Maybe","cardTrapDire":"Maybe","cardAmazon":"Maybe","cardBlind":"Maybe","cardChalice":"Maybe","cardClan":"Maybe","cardDiin":"Maybe","cardDivine":"Maybe","cardDwarf":"Maybe","cardElf":"Maybe","cardFeayn":"Maybe","cardGangland":"Maybe","cardGohlen":"Maybe","cardLorigg":"Maybe","cardOutlands":"Maybe","cardRedblade":"Maybe","cardRegian":"Maybe","cardRunespawn":"Maybe","cardSelurin":"Maybe","cardThyrian":"Maybe","cardToryn":"Maybe","cardAmbrosia":"Maybe","cardAmuletofPower":"Maybe","cardArcaneEnergies":"Maybe","cardBanish":"Maybe","cardBarkeep":"Maybe","cardBattleFury":"Maybe","cardBlacksmith":"Maybe","cardClaymore":"Maybe","cardCreepingDeath":"Maybe","cardCursedMace":"Maybe","cardFeast":"Maybe","cardFireball":"Maybe","cardFlamingSword":"Maybe","cardForesightElixir":"Maybe","cardGoodberries":"Maybe","cardHatchet":"Maybe","cardIllusoryBlade":"Maybe","cardLantern":"Maybe","cardLightstoneGem":"Maybe","cardMagiStaff":"Maybe","cardMagicMissile":"Maybe","cardMagicalAura":"Maybe","cardPawnbroker":"Maybe","cardPolearm":"Maybe","cardSage":"Maybe","cardShortBow":"Maybe","cardShortSword":"Maybe","cardSpear":"Maybe","cardTavernBrawl":"Maybe","cardTaxCollector":"Maybe","cardTownGuard":"Maybe","cardTrainer":"Maybe","cardWarhammer":"Maybe"}
I'm using libraries for the JSON and for setting/getting the cookie. Both that early version and the latest use the exact same versions of the exact same libraries.
The only thing I can think of is that the cookie has gotten a bit more than twice as long. Before URI encoding, we're talking 4000 characters vs. 1800 characters. Also, I URI encoded the more recent cookie and manually set it myself, and the browser accepted it just fine, and my program loaded it just fine.
I'm completely out of ideas here. Help!
You should really store all this data in a session on the server if possible, rather than having a massive cookie. Then you can simply request data via AJAX or embed it in each page request. Browsers are only required to provide 4KB of space per cookie, so if you're over that there's a chance it might not be stored.
4096-byte limit; otherwise entire cookie is discarded by IE. http://support.microsoft.com/kb/306070