138

enter image description here

What is the difference between local.test.com and .local.test.com ? The screenshot is from Chrome.

ripper234
  • 222,824
  • 274
  • 634
  • 905
  • http://stackoverflow.com/questions/2285010/php-setcookie-domain – Uwe Keim Mar 08 '12 at 13:16
  • In comment from user2864740 Sep 26 '16 at 16:44 - Link is dead, apparently erik.io domain has passed on to another user or domain registrar. – qxotk Jul 08 '20 at 19:04

4 Answers4

123

The leading dot means that the cookie is valid for subdomains as well; nevertheless recent HTTP specifications (RFC 6265) changed this rule so modern browsers should not care about the leading dot. The dot may be needed by old browser implementing the deprecated RFC 2109.

RFC 6265 section 4.1.2.3

For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)

Community
  • 1
  • 1
Timido
  • 1,646
  • 2
  • 13
  • 16
  • 2
    The RFC is dated April 2011. Both IE8 and IE9 were initially released before that date and - sadly - are still used. So my best guess (didn't try) is that they need the leading dot. Does anybody know of an estimation how many browsers in the wild are still running on the old RFC? – BlaM Jan 20 '16 at 11:08
  • http://erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains/ recommends using a leading dot for best-compatibility when wishing to include sub-domains. This compatibility requirement will only continue to decrease. (Not required for 6255, but required and with same end result as for 2109.) – user2864740 Sep 26 '16 at 16:51
67

local.test.com will be used for the domain, while .local.test.com will be used for subdomains too.

JoRouss
  • 2,864
  • 2
  • 22
  • 40
  • 12
    So `local.test.com` will not apply to `x.local.test.com`, but `.local.test.com` applies both to `local.test.com` and to `x.local.test.com`? – ripper234 Mar 08 '12 at 13:22
  • 42
    I believe this is incorrect. Cookies are shared with any and all downstream subdomains, with or without a dot. You can think of subdomains as "inheriting" cookies from their parent. So setting a cookie on example.com sets it on blog.example.com and my.blog.example.com. Setting a cookie on blog.example.com sets it on this.is.my.blog.example.com and every subdomain in between. But, just like inheritance, the reverse is not true. Setting a cookie on blog.example.com does not set it on example.com. – geddski May 03 '14 at 08:44
  • 12
    That said, you CAN limit the cookie to just the host by not setting the cookie's domain at all (or setting to empty string). That, strangely, will set the cookie for just the host (example.com) and not any of its subdomains. – geddski May 03 '14 at 08:44
  • If "local.test.com" will be shared with subdomains *depends* on if the Cookie's domain was set in Set-Cookie and which browser is used! Unless explicitly in the subdomain restricted context it is 'safer' to assume that *also* matches subdomains. See http://erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains/ ; I've included the conclusions in another answer. – user2864740 Sep 28 '16 at 02:11
  • 14
    To clarify based on another answer, the dot *used* to make a difference, but now it doesn't. The cookie will be sent to any subdomain of the specified domain, with or without the leading dot. What actually controls whether it's passed to subdomains is *whether* you set a domain on the cookie or not. If you set no domain at all, then the cookie will only be sent to the exact domain that issued it. It will never be sent to less-specific parent domains (e.g. "local.test.com" will not be included in requests to "test.com"), and it will only be sent to matching subdomains if you set a domain value. – Triynko Nov 04 '16 at 16:09
  • 4
    @Triynko, the dot makes a difference when you are tying to update a cookie. I have not managed to isolate all the rules, but I have seen results vary based on the presence of the leading dot or not, and it not straight forward. How this works varies by browser and is not all intuitive. Controlling whether or not a cookiename has a leading dot on the browser is not the simplest programming task I ever did. – DanAllen Jun 12 '17 at 00:18
  • IE behavior is different in this regard. See https://github.com/js-cookie/js-cookie/tree/8b70250875f7e07445b6a457f9c2474ead4cba44#domain. – Fagner Brack Jul 28 '17 at 07:00
  • 2
    In Chrome 83 I can still have two separate cookies with the same name but one for the domain `.acme.com` and another one for `acme.com`, so the dot does make a difference when you try to update/delete a cookie. – Tom Pohl Jul 01 '20 at 08:05
18

From the article The definitive guide to cookie domains and why a www-prefix makes your website safer:

Conclusion

Although the definitions are somewhat different, we can simplify it for any of these implementations as:

  • When no domain is set in the cookie, the cookie should only match the exact host name of the request. [NOTE: this is different from returning a Set-Cookie with a domain without a dot!] No sub domains, no partial matches. This means simply not including the domain attribute – it is not valid to set an empty domain attribute. Unfortunately, Internet Explorer appears to treat this as the host name along with any subdomains.

  • When setting a domain in the cookie, the safe choice is to have it preceded by a dot, like .erik.io. The cookie will match with all sub domains.

  • Setting a cookie domain without a preceding dot, like erik.io, is invalid in RFC 2109 implementations, and will produce the same behaviour as with a preceding dot on other implementations. There is no way to restrict a cookie to a specific explicitly set domain, without sub domains being included.

Other worthwhile observations:

  • In all RFCs, a specified cookie domain must match the current host name, per normal matching. Setting a cookie for www.erik.io in a response from erik.io is not valid, as a cookie with domain www.erik.io does not match erik.io, the former being more specific.

  • In RFC 6265, domains are explicitly lower cased when parsing the Set-Cookie header.

user2864740
  • 60,010
  • 15
  • 145
  • 220
7

The leading dot in ".local.test.com" is just how chrome views cookies with a "Domain=local.test.com" set (or a "Domain=.local.test.com", which is the same).

Set-Cookie definitions without "Domain=something" views the domain (=host) without a leading dot.

So the leading dot in chrome don't reflect whether or not a leading dot was used from the server, but whether or not that cookie had a "Domain=something" in its definition from the server. (And if it had, the cookie will also be sent to sub-domains).

At least this is what my tests show. Chrome should make this easier to read, for instance view the exact string that defined the cookie and when it was received.

Kjetil S.
  • 3,468
  • 20
  • 22