What does the dot prefix in the cookie domain mean?

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

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.)

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

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.

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.