怎么纠结上的

近期在准备借鉴云风的 skynet 来完善我们的架构。这个 Cookie 研究是个插曲。

我这有个 HTTP Server 只做与数据库的代理接口用，同事那边有个 HTTP 的 Web Server，他的 Server 需要以 HTTP Client 身份来访问我的 Server 取数据。

我的 Server 用的 Node.js 写的 Express，访问流程为先去一个 path 验证，验证完，这个 HTTP Client 就可以访问其他 path 了。验证的时候会标记 Client 对应的 Session 为已验证，之后的每次访问会检查这个标记。

对 Cookie 的认识加深了些

这里的 Cookie 流程是这样的，验证之后，Server 会在 response 的 headers 里设置上“set-cookie”的值，接下来的 request 需要带上这个 Cookie，否则 Server 认为这个 Client 没有被验证。

第二次 request 的 response 里可能会给设置新的 Cookie，第三次 request 需要带上第二次 respones 设置的 Cookie……

这样就是每次访问带上上次返回的 Cookie，Server 才会认为你这次的访问启用的 Client 已经被验证过。

Node.js 里的 http.request 默认是不会捎上 Cookie 的，所以得自己封装下。

PS

Cookie 的 Wikipedia：http://en.wikipedia.org/wiki/HTTP_cookie#Implementation

Cookie 以前做模拟登陆时有想研究过，那时对 HTTP 完全不了解，加上其他的事情，给放弃了。这次总算稍微留个感性认识了。

这里写的乱七八糟的，回头有空再完善这篇吧。

同一个站点的 Cookie 不一定只是登陆够给的那个，而且 Cookie 也不局限于用于登陆标记。例如登陆后浏览好久，开始启用某个功能需要做标记，Cookie 字段就动态增加了。为此在给 Node.js 的 http.request 封装的维护 Cookie 的 Agent 后来修改了。

这些内容在《Http权威指南》里将很清楚，经典书才是硬道理。