关于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上的这个有个截图，看着说明就直观很多了。