关于cookie domain中的点前缀

今天同事遇到一个问题，大概描述以下：

浏览器已经接收指令，以前在一级域名下存储了相关的信息。这里为了简化问题，假设咱们有两个应用A和B，域名分别为：a.b.com和c.a.b.com。（显然B是A的一个子域）。

上面的描述就是：在.b.com这个一级域名下，咱们已经成功写入了一个cookie，假设为：b=level1。

在正经常使用户的浏览行为中，应用A会向本身的域下写入a=level2(domain:a.b.com)。

在A正常的页面中，有些场景会有异步的请求发出到B应用的页面（用于获取数据），合理的一种想法是：发送到B应用的请求，应该携带着上面的b=level1，a=level2这两个cookie信息到B应用的服务器去才对。可是，实际的状况是，b=level1被如愿携带上来，可是a=level2这个信息却被丢弃了！（确切的说是没有跟着request一块儿被发送到B的服务端）。

为啥？在访问子域应用时，不是父域名下的cookie都应该被携带上来吗？就像上面的b=level1那样？

其实，关于这点，在cookie的RFC规范中，并无太明显的说明，至少我没有看到，即便又看了一遍RFC6265中关于Domain Matching的描述也是如此。

但实际的使用过程当中，某个域下的cookie若是但愿可以被他的子域具备可见性（便可以读取），必需要注意的一点是，应该保证这个cookie在被Set的时候，应该以"."开头。回到上面的例子，之因此a=level2这个cookie没有在用户浏览器请求B应用时被携带到B的server端，就是由于a=level2这个cookie的domain不是.a.b.com，而是a.b.com。

事实上，上面例子中的A应用，在向本身的域名下写入a=level2这个cookie时，压根就没有显示的设置domain这个属性，这样一来，浏览器接受到这个Set Cookie的请求时，就会以默认以当前应用的域名做为cookie的domain。（不过听说某些版本的Firefox到是会自做聪明的在当前域名的前面自动加上一个点，这个待验证！）

这一个小点的区别，仍是很容易被忽略的，不过产生的浏览行为仍是有细微差异的。（涉及到cookie是否上传，是否占用网络流量等）

PS：关于上面说到的那个问题，stackoverflow上的这个有个截图，看着说明就直观不少了。