6

Here is one that is throwing me for a loop. I am trying to set a simple cookie that has one name:value pair on IE8. Tested on FF and it works fine. IE8 keeps blocking it.

I have read about the P3P stuff and created a basic P3P doc, no errors reported by the IBM tool, and added the following on all pages:

<meta http-equiv="P3P" CP="CAO DSP COR PSDa CONi TELi OUR STP COM NAV"><link rel="P3Pv1" href="/w3c/p3p.xml"></link>

The code I use to set the cookie is as follows:

function setCompatibilityCookie(c_name, value, expiredays) {
var exdate = new Date();
exdate.setDate(exdate.getDate() + expiredays);
document.cookie= c_name + "=" + escape(value) + ((expiredays==null) ? "" : ";expires=" + exdate.toUTCString());}

Any ideas why IE8 keeps blocking me from setting this cookie?

Thank you, Schalk

schalkneethling
  • 6,327
  • 3
  • 21
  • 20
  • 1
    Are you setting the cookie from a "third-party" document (i.e. in an IFRAME) ? – Philippe Leybaert Jun 01 '10 at 19:05
  • Nope, it is just an HTML page. I have actually isolated the code to a simple HTML page that has two links, one that sets the cookie and another that gets the cookie value and prints it to the page. This works perfectly in Firefox but in IE8 as well as Chrome the cookie is never set. – schalkneethling Jun 02 '10 at 11:15
  • Have now tested it on IE6 running in a virtual machine and it is being blocked there as well, so this is some freaky IE thing. Anyway, you can see the latest code I am using here : http://pastebin.com/yB8WSDjW – schalkneethling Jun 03 '10 at 05:46

6 Answers6

2

I had the same problem and spent a lot of time digging why IE wont save my JS cookie. My P3P stuff was OK and IE was saving response cookies, but not JS.

Suddenly and most surprisingly I found the solution by removing the following line from html:

< meta http-equiv="Content-Type" content="text/html; charset=utf-8"/ >

I have no idea why that happens but that solved all my problems. Hope this helps someone.

EvilDuck
  • 4,386
  • 23
  • 32
1

One problem may be that you're using getDate(), which returns the day of the month. If your expiredays is too great, it should roll over to next month, but in IE it may be staying in this month and expiring right away. Maybe try this:

function setCompatibilityCookie(c_name, value, expiredays) {
var exdate = new Date();
exdate.setTime(exdate.getTime() + (expiredays * 86400000));
document.cookie= c_name + "=" + escape(value) + ((expiredays==null) ? "" : ";expires=" + exdate.toUTCString());}
Andrew
  • 14,204
  • 15
  • 60
  • 104
  • Hi Andres, thanks for the suggestion, I have tried it but the problem still persists. Please see my comment on Philippe's question above. – schalkneethling Jun 02 '10 at 11:16
  • Ok, the reason why chrome was 'blocking' my cookie was because of this issue http://code.google.com/p/chromium/issues/detail?id=535, you can read more about how to resolve this over here: http://stackoverflow.com/questions/335244/why-does-chrome-ignore-local-jquery-cookies : Now it is just IE8, what a surprise ;) – schalkneethling Jun 02 '10 at 11:23
  • So your page was being loaded off the local file system and not off a remote server? I think this is your IE problem as well. I know I've encountered this before, years and years ago. Basically, whenever you're loading a file off a local resource (your hard drive or a local share) the browser behaves completely differently. In IE you used to be able to do nearly anything you wanted locally (HTAs were amazing). Then the security model changed and the party was over. Are you developing an app that is meant to run locally or are you just using your local drive for development and testing? – Andrew Jun 02 '10 at 16:06
  • Hey Andrew, I experienced the problems initially running a page of a server. But I then isolated the problem and tested of a local file. I have looked at the source of the jQuery Cookie plugin to see how it was done and it seems I might have found the problem. Still need to test it as I think IE8 might allow setting cookies from a local file but not reading, not entirely sure. Will let you know as soon as I have tested it on the server. – schalkneethling Jun 02 '10 at 17:34
  • Ok, I tried it on the server now.... No luck :( Might running from an IP as apposed to a URL make a difference here? It seems that other cookies are being blocked even before I attempt to set this one. So now I wonder whether there are different restriction placed when running from an IP as apposed to a specific domain. It seems IE8 is placing the IP in the list of restricted sites by default. Does this ring a bell for anyone? – schalkneethling Jun 02 '10 at 21:42
  • IP vs domain shouldn't make a difference. What happens if you drop the p3p declarations? After setting the cookie but immediately before interacting with the server, does the document.cookie value reflect your changes? After setting the cookie and then interacting with the server, does document.cookie change at all? Are you able to capture the raw HTTP cookie value on the server side? If not, try running it through Fiddler2 to see what the HTTP request headers look like. You may have to also specify the domain and maybe the path in your cookie. Could there be another process writing cookies? – Andrew Jun 02 '10 at 22:59
1

I have been using the same code for ages for setting cookies on the client side with no problem whatsoever. I would definitely investigate on IE setup instead of the code itself. In IE, you have a big bunch of possibilities to say if you accept cookies or not depending on the source (as you spotted it). I would definitely start here! Good luck

Zaziffic
  • 346
  • 2
  • 9
0

I ran in to this issue as well, and it turns out it had to do with the length of the cookie name. In this case I had a cookie name that was 26 characters and this works fine in anything but IE 8 and below. I shortened the name to only have 10 characters and all of a sudden IE 8 was reading/writing the cookie just fine. I am assuming the arbitrary limit here is 16 characters for an IE 8 cookie name.

tbjers
  • 564
  • 3
  • 13
0

I experienced this and tried some of the responses here, my issued turned out to be the expiry. I'd set it for 99999999999, but when I dropped this down to 9999999 it worked. It seems IE8 has a limit on the expiry (genius Microsoft, pure genius :s)

Simon Stevens
  • 424
  • 1
  • 5
  • 13
0

I've faced the same situation and the problem was that... expiredays is such a keyword ONLY for IE. If you change the name of expiredays variable in whateveryouwant, it works well on all browsers.

Echilon
  • 10,064
  • 33
  • 131
  • 217
Carlo
  • 1