Please read my blog's comment policy here.
Over the five years I’ve worked on Internet Explorer, I’ve probably seen more questions from the community about HTTP cookies than on any other topic. Cookies are an integral component of most websites in use today, and hence problems or unexpected behaviors with cookies tend to get a lot of attention.
In this post, I’ll try to summarize the most common questions and answers I’ve seen related to Internet Explorer’s implementation of cookies. I may add to this FAQ over time.
Q1: IE’s cookie code doesn’t seem to support <something> as defined in RFC2109 or RFC2965.
A: Correct. Internet Explorer (including IE8) does not attempt to support any RFC for cookies.
WinINET (the network stack below IE) has cookie implementation based on the pre-RFC Netscape draft spec for cookies. This means that directives like max-age, versioned cookies, etc, are not supported in any version of Internet Explorer.
Q2: If I don’t specify a leading dot when setting the DOMAIN attribute, IE doesn’t care?
A: Correct. All current version browsers (Chrome, FF, Opera, etc) seem to treat a leading dot as implicit. Here’s a test case.
Q3: If I don’t specify a DOMAIN attribute when a cookie, IE sends it to all nested subdomains anyway?
A: Yes, a cookie set on example.com will be sent to sub2.sub1.example.com.
Internet Explorer differs from other browsers in this regard. Here’s a test case.
Q4: How many cookies will Internet Explorer maintain for each site?
A: As of August 2007, the per-host limit was increased from 20 to 50. The August update applied to IE5, 6, and 7. IE8 natively can support 50 cookies per host, and Firefox uses the same limit.
It’s worth mentioning that increased cookie limit actually broke the website of a major financial institution. The site depended on cookies beyond the 20 cookie limit getting dropped, and stopped working properly when the limit was increased. This is just one example of how tightly-coupled today’s web is to IE’s cookie implementation. That, in turn, is one reason why the IE team must exercise great care when making any change to IE’s cookie implementation.
The document.cookie property is limited to 10KB.
WinINET will not respect a Set-Cookie response header value longer than 5118 bytes. WinINET allows 50 cookies, each of which is ~5kb long. Hence a request could carry 250kb of cookies. (eek!)
Q5: IE won’t set a cookie when the hostname/domain contains an underscore?
A: Correct. Technically, underscore is not a DNS character, and while Windows will let you use an underscore when naming your machine, it warns you that doing so may cause problems. One such problem is that WinINET blocks attempts to set cookies on such domains.
Q6: IE won’t set a cookie for certain domains, like those of the format http://xx.yy?
A: Correct. The idea is that you may not set a cookie on a "top-level" domain shared by unrelated organizations. Historically, ccTLDs of the format xx.yy were effective TLDs, so cookies may not be set on them. While this heuristic was never perfect, it's been unchanged for over 15 years and hence is not likely to change any time soon. The intricacy of this issue merits a long blog post all its own-- see this post.
Q7: My site is not receiving cookies when it is running in an IFRAME and the parent page is from a different domain. Why?
A: Internet Explorer has restrictions on “3rd party” cookies. 3rd party cookies are cookies which are set or sent for resources from a different domain than the top-level browsing context. You can easily confirm P3P/Cookie restrictions as the root cause of such issues by temporarily changing IE’s Tools / Options / Privacy setting to “Accept All Cookies”.
In order to allow such cookies to be sent reliably, you should send a P3P header when setting the cookie.
You can use Fiddler’s “Privacy Inspector” to view and analyze any P3P Policy. To learn more about Internet Explorer’s support for P3P, please see MSDN.
Q7b: My page doesn't receive or set cookies when it is running in an IFRAME with the SECURITY=RESTRICTED attribute. Why?
A: The SECURITY=RESTRICTED attribute on IFRAMEs indicates that the browser should treat the content as if it came from the Restricted Sites zone. Content in this zone cannot set or read cookies. Cookies will not be sent to the server, and cookies will not be set if received from the server. To resolve this problem, you will need to communicate any necessary state information to the server via another mechanism (e.g. a token in the URL).
Q8: Are there any limits to the HTML DOM document.cookie property?
A: In IE5, 6, and 7, if the cookie string is longer than 4096 bytes, the document.cookie property will return an empty string. For IE8, this limit was increased to 10Kb.
Also, due to an obscure bug in the underlying WinINET InternetGetCookie implementation, IE’s document.cookie will not return a cookie if it was set with a path attribute containing a filename.
For instance, if a page sets a cookie on itself like so:
…the cookie will be sent with HTTP requests but will not appear in the document.cookie collection.
Q9: Cross-Site Scripting attacks (XSS) can steal cookies. What can I do?
A: Determine if you need to expose your cookies to scripts running on your site. If your cookies are only used by your server, and your scripts don’t require access to your cookies, use the HttpOnly attribute to help protect your site against cookie theft via cross-site scripting attacks.
Simply add the HttpOnly attribute to each Set-Cookie header, and Internet Explorer will ensure that your cookie is not available to any script running in your pages. Cookies with the HttpOnly attribute are still sent in each HTTP request, but will not appear in the script-accessible document.cookies property. This means that if a hacker finds a cross-site scripting hole in your site, he cannot easily use the hole to steal logged-on visitors’ cookies.
The HttpOnly attribute is supported in all modern browsers (IE6+, FF3+, Safari 4, Chrome, Opera 9.5+).
Q10: How can applications or native code add-ons set cookies?
A: Applications should set cookies using the InternetSetCookieEx function, passing the appropriate flags to indicate if a cookie is being set from a 3rd party context, and any P3P directives available. The non-EX version of this function will unconditionally set a cookie (even if “Block all cookies” is set in IE’s settings) although such cookies will not be subsequently sent to servers while the “Block all cookies” setting is active.
Note: On Windows Vista and above, Internet Explorer runs Internet content in Protected Mode, a sandbox with an isolated cookie store. In order to set a cookie in the Protected Mode sandbox from an external application running at Medium integrity (aka outside of Internet Explorer), you must use the IESetProtectedModeCookie function. This API was added in IE8, and unfortunately, there is no straightforward alternative for IE7. This API has a number of limits, in particular, it cannot be called by processes running at High Integrity (Admin), and it does not have an option to provide the P3P policy string when setting the cookie.
Q11: How can applications or native code add-ons retrieve cookies?
A: Use the InternetGetCookieEx function.
Note, by default, the cookies returned from this function will not include any HTTPOnly cookies. To retrieve HTTPOnly cookies, you must pass the INTERNET_COOKIE_HTTPONLY flag, available in IE8+. If you decide to pass this flag, you must ensure that your code will not expose the returned value to any script-controllable context. (Note: It appears that support for the INTERNET_COOKIE_HTTPONLY flag was added to IE7 in a cumulative update (KB960818)).
Note: On Windows Vista and above, Internet Explorer runs Internet content in Protected Mode, a sandbox with an isolated cookie store. In order to get a cookie from the Protected Mode sandbox from an external application running at Medium integrity (aka outside of Internet Explorer), you must use the IEGetProtectedModeCookie function. This API was added in IE8, and unfortunately, there is no straightforward alternative for IE7. This API has a number of limits, in particular, it cannot be called by processes running at High Integrity (Admin).
Q12: How can I log into my web application multiple times? How are cookies shared between IE windows?
A: Good question, and the answer has changed a bit in IE8. I wrote up a full post on the subject over on the IEBlog.
Q13: How can I control (block, downgrade or allow) cookies?
A: See Internet Explorer Cookie Controls.
That’s it for now; thanks for reading!
Just one more reason why IE8 should be the end of the line, so that Microsoft can start afresh on a new browser that isn't tied to these archaic problems.
@Dan: I'm not sure exactly what you're suggesting.
Starting over would solve nothing at all-- no websites would magically start to work. Generally speaking, no compatibility problems would magically disappear, although we could trade some compat problems for other compat problems.
I am using sessions in my application.(Its a asp.net application).If I am blocking all the cookies it does not allow me to proceed from login page in IE8.But in IE6 it allows me to proceed further. How session cookies are exactly affected if I am blocking all cookies in IE6 and IE8.
Sheetal: If you're actually blocking all cookies, then you're blocking session cookies too. But without more repro-steps, it's really impossible to say what you're seeing.
I'm trying to set cookies for my website. I add a Set-Cookie: attribute to my HTTP header with expiration, domain, and path attributes set.
Everything works fine in Firefox.
Internet Explorer does not seem to accept any of my cookies. This happens even when I put privacy settings to the minimum or turn everything off. What could be the cause of this? (testing on IE8)
Chris, you'll need to either provide a public URL, or a traffic capture (www.fiddler2.com) to debug this.
Thanks a lot for the response.
I am working with fiddler now and it is a big help. I wish I had known about it a while ago.
Before downloading fiddler, however, I did some trial and error with my headers to see if there was something wrong with my syntax. I found that when the 'expires' argument in a 'Set-Cookie:' header is removed, the cookie is actually stored. I have tried poking around to see what I need to do to make it work for IE but have not found anything.
@Chris: What specifically was your Expires element's value? If it was in the past, then the cookie will be deleted. If it was malformed (e.g. using a non-GMT timezone) the cookie should be downgraded to a session cookie.
Thanks for the feedback. I was being careless and assumed my timezone was EDT. One off from EST. So my dates were mixed up. I feel stupid admitting such a careless bug. I'd like to thank you for your responses.
I have an application that allows users to customize the app by entering info on the web page my app is downloaded from. The page stores the info in a cookie on the users machine. Pre Vista I used InternetGetCookie to read the cookie then deleted the cookie by setting a past expire date using InternetSetCookie. This prevented the cookie from being read each time the app starts and potentially reseting changes a user may make.
With the advent of protected mode I am using IEGetProtectedModeCookie and am trying to use IESetProtectedModeCookie to expire the cookie. It appears the set function is creating another cookie (with the expire date) rather than updating the current cookie.
Is that normal and if so is there a way to expire an existing cookie?
@John: Is the cookie that you're trying to expire a session cookie or a persistent cookie?
If you have a simple demo app, I'm happy to take a look. Use the Email link at the top-right of this page to contact me. Thanks!
Here is some odd IE8 behavior that threw me for a loop today. My site X is using an iframe to make a transaction using site Y. (See http://dev.braintreepaymentsolutions.com/payment-processing/transparent-redirect/ for an example of why one would do this.) Site X uses cookie-based sessions.
The page on X has a form that posts to Y. Y responds by redirecting to another page on X that interprets the result, puts a message in the cookie, and redirects back to the first page on X.
In trace form:
GET //x/form -> 200, Set-Cookie C1
POST //y/process_form -> 302 to //x/result
GET //x/result -> 302 to //x/form, Set-Cookie C2
GET //x/form -> 200
The problem is that although X is setting its own cookie to C2, IE is ignoring it and sending cookie C1 in the last GET.
My theory is that because the //x/result GET is a redirect from host Y, IE is treating the cookies from that response as if they came from host Y. Since host Y has no P3P header, cookie C2 is thrown away.
Setting a P3P header on host X's response when setting the C2 cookie solves the problem.
I am wondering if this is expected behavior. Should first-party cookies be rejected because they came from a redirect?
I am using "InternetSetCookieW " call to create cookie from my application.
On Vista + IE7:
This creates cookie in location c:\windows\temp. As per IE7 settings, it is reading cookie from location "C:\Users\dipti\AppData\Local\Microsoft\Windows\Temporary Internet Files"
I am suspecting some setting is causing this. Can you help me to understand why InternetSetCookieW writing cookie at different location than the location set for IE?
@dipti: Regardless of where the file lives, do you see the cookie get sent?
@walter: I'd love to see a network capture (www.fiddlercap.com) of your scenario. You can mail it to me using the Help > Send Feedback link in FiddlerCap/Fiddler.
Thanks for the reply.
It is a persistent cookie and I can see the cookie getting created at location "%windir%\temp". But when I launch the URL which is expecting that cookie fails because IE is looking for cookie at location "%userprofile%\cookies"
I am suspecting some group policy is causing this kind of behavior, but not very sure.
Any guide-line to proceed further would help.