cookie域中的点前缀是什么意思？
local.test.com和.local.test.com什么.local.test.com ？ 屏幕截图来自Chrome。
local.test.com将用于域名，而.local.test.com也将用于子域名。
领先的点意味着cookie也适用于子域名; 不过最近的HTTP规范（RFC 6265）改变了这个规则，所以现代浏览器不应该关心这个主要的点。 旧的浏览器实现不推荐的RFC 2109可能需要点。
RFC 6265第4.1.2.3节
例如，如果“域”属性的值是“example.com”，则在向example.com，www.example.com和www.corp.example发出HTTP请求时，用户代理将在Cookie标头中包含Cookie。 COM。 （请注意，即使不允许该字符，也会忽略前导的％x2E（“。”）（如果存在），但如果存在，则会跟踪％x2E（“。”）将导致用户代理忽略该属性。 ）
从文章“Cookie的权威指南”以及为什么www-prefix使您的网站更安全 ：
结论
尽pipe定义有些不同，但是我们可以将这些实现简化为：
当cookie中没有设置域时，cookie应该只匹配请求的确切主机名。 [注意：这不同于返回一个没有点的域的Set-Cookie！]没有子域，没有部分匹配。 这意味着不包括域属性 – 设置一个空的域属性是无效的。 不幸的是， Internet Explorer似乎将此视为主机名以及任何子域 。
在cookie中设置域时，安全的select是在它之前加上一个点，比如.erik.io。 该cookie将与所有子域相匹配。
设置一个没有前导点的cookie域，如erik.io，在RFC 2109实现中是无效的，并且会产生与其他实现上的前一个点相同的行为。 没有办法将cookie限制到特定的明确设置的域，没有包含子域。
其他有价值的观察：
在所有RFC中，指定的Cookie域必须与当前主机名匹配，按照正常匹配。 在erik.io的响应中为www.erik.io设置一个cookie是无效的，因为域www.erik.io的cookie与erik.io不匹配，前者更具体。
在RFC 6265中，在parsingSet-Cookie头时，域显式地被降低了。
“.local.test.com”中的最前面的点就是chrome如何通过“Domain = local.test.com”设置（或“Domain = .local.test.com”）来查看cookie。
没有“Domain = something”的Set-Cookie定义查看没有前导点的域（= host）。
因此，chrome中的前导点并不反映服务器是否使用了前导点，而是该cookie是否在服务器的定义中包含“Domain = something”。 （如果有的话，cookie也会被发送到子域）。
至less这是我的testing显示。 Chrome浏览器应该更容易阅读，例如查看定义cookie的确切string以及接收时间。
