HTTP 代理如何正确处理 Cookie

HTTP 代理如何正确处理 Cookie
大多数的 Web 应用程序都要求维护某种会话状态，如用户购物车的内容。这种会话状态的保持很多情况下需要借助于 Cookie 或者 Session 的帮助。本文结合在线页面翻译 （Machine Translation System）项目中对于 Cookie 的处理方法，探讨一下如何在 HTTP 应用代理中正确处理 Cookie 的传递和管理问题。

读者定位为具有 Java 和 Web 开发经验的开发和设计人员。

读者可以学习到关于 Cookie 的工作原理和 Cookie 协议的细节，以及在一个 HTTP 应用代理的场景下 Cookie 的管理和处理思想，并可以直接使用文中的代码和思路，提高工作效率。

随着越来越多的系统移植到了 Web 上，HTTP 协议具有了比以前更广泛的应用。不同的系统对 WEB 实现提出了不同的要求，基于 HTTP 协议的网络应用正趋于复杂化和多元化。很多应用需要把用户请求的页面进行处理后再返回给用户，比如页面关键字过滤，页面内容缓存、内容搜索、页面翻译等等。这些应用在实际效果上类似于一个 HTTP 应用代理：它们首先接受用户的请求，根据用户请求的 URL 去真正的目标服务器取回目标页面，再根据不同应用的要求做出相应处理后返回给用户。这样用户直接面对的就是这个 HTTP 应用代理，而通过它与其他页面进行交互。Cookie 或 Session 技术的应用，解决了 HTTP 协议的一个问题 – 无法保持客户状态，因此它现在被广泛应用于各种 Web 站点中。上面提到的那些应用如果不能处理好 Cookie 和 Session 的传递、更新和废除等问题，就会极大的限制它们所能处理站点的范围，因此如何在 HTTP 应用代理中正确处理 Cookie，成为一个必须解决的问题。本文结合在页面翻译（Machine Translation System）项目中对于 Cookie 的处理方法，探讨一下这方面的解决方案。

MTS 项目简介及讨论前提
Machine Translation System（以下简称 MTS）是一个在线实时页面翻译系统，为用户在线提供把英文页面翻译成其他 9 种语言的服务。用户通过向 MTS 系统提交一个类似下面的 URL 使用此服务，其中参数 url 指明了用户所需要翻译的目标地址，参数 language 指明了所需翻译成的目标语言，www.mts.com 是假想中提供 MTS 服务的站点。

一个完整的 MTS 系统处理过程可以分解成以下几个步骤：

用户向 MTS 提交合适的 URL。
MTS 在接到用户的请求后，解析出用户需要翻译的目标地址和目标语言，根据用户请求的目标地址，把请求转发到目标服务器。
MTS 接受来自目标服务器的应答，包括页面信息和 HTTP 头信息。
MTS 在确定得到正确的目标页面后，把页面内容送入 WebSphere Translation Server 进行翻译。
把翻译后的页面连同修改后的 HTTP 头信息提交给用户。
MTS 逻辑图
MTS 逻辑图
当然，这其中涉及到很多的应用处理。比如与各种 HTTP/HTTPS 站点建立联结、根据 HTTP 头信息进行页面跳转和错误处理、为始终保持用户在翻译模式下而对目标的 HTML 页面进行分析和修改，根据系统设置对某些 DNT（Do Not Translate）的页面进行过滤和跳转，当然还有对 Cookie 的处理等等。其他问题跟这篇文章关联不大，我们重点讨论在这种情况下的 Cookie 处理。Cookie 跟随目标服务器的 HTTP 头信息被 MTS 接收到，经过 MTS 整理之后发给客户端浏览器。MTS 在接到下一次用户对同一个站点的翻译请求时，再把从客户端得到的 Cookie 发送给目标服务器。

在以上的场景中，MTS 充当的作用类似于一种 HTTP 应用代理服务器，它代替用户取得目标页面，并在作出相应处理后再提交给用户。当然，这种代理服务器不需要用户修改浏览器的代理服务器参数或者网络配置，而只是简单的在浏览器的地址栏中输入一个 MTS 能够识别的 URL 即可。此篇文章也是在这样一个应用场景的基础上，展开对 HTTP 应用代理服务器如何处理 Cookie 的讨论。

问题的产生
在 MTS 系统中，目标服务器的 Cookie 在两个地方会产生问题。当 MTS 接收目标服务器应答的时候，Cookie 随着 HTTP 头信息被 MTS 接收到的。这时候目标服务器认为 MTS 就是最终客户，因此它赋予了 Cookie 与目标服务器相符的属性。而如果 MTS 把这些 Cookie 原封不动的保存在 HTTP 头信息中，传给真正的最终用户的话，用户的浏览器会因为这些 Cookie 不合法而忽略它们。同理，当 Cookie 从浏览器端传回目标服务器的时候，也会遇到相同的问题。因此有必要对 Cookie 进行一些处理，以保证用户的浏览器能真正识别和利用这些 Cookie。

但是为何用户浏览器无法识别从目标服务器传过来的原始 Cookie 呢？这是因为出于安全性的考虑，Cookie 规范制定的时候对 Cookie 的产生和接受设置了一些严格的规范，不符合这些规范的 Cookie，浏览器和服务器都将予以忽略。下面我们从 Cookie 规范入手进行介绍。

Cookie 的规范介绍
目前有以下几种 Cookie 规范：

Netscape cookie 草案：是最早的 cookie 规范，基于 rfc2109。尽管这个规范与 rc2109 有较大的差别，但是很多服务器都与之兼容。
rfc2109， 是 w3c 发布的第一个官方 cookie 规范。理论上讲，所有的服务器在处理 cookie( 版本 1) 时，都要遵循此规范。遗憾的是，这个规范太严格了，以致很多服务器不正确的实施了该规范或仍在使用 Netscape 规范。
rfc2965 规范定义了 cookie 版本 2，并说明了 cookie 版本 1 的不足。
rfc2965 规范的使用，目前并不多。rfc2109 规范相应要严格得多，在实际应用上，并不是所有的浏览器和 Web 服务器都严格遵守。因此相比较而言，Netscape cookie 草案倒是一个比较简洁和被广泛支持的 Cookie 规范，因此我们在这里以 Netscape cookie 草案为基础进行讨论，对于其他两种规范，我们的讨论和代码具有相同的意义。关于 Netscape cookie 草案的细节，大家可以参照 Netscape 官方站点，这里我们列举一些和我们讨论有关的内容。

根据 Netscape cookie 草案的描述，Cookie 是 Web 服务器向用户的浏览器发送的一段 ASCII 码文本。一旦收到 Cookie，浏览器会把 Cookie 的信息片断以"名 / 值"对 (name-value pairs) 的形式储存保存在本地。这以后，每当向同一个 Web 服务器请求一个新的文档时，Web 浏览器都会发送之站点以前存储在本地的 Cookie。创建 Cookie 的最初目的是想让 Web 服务器能够通过多个 HTTP 请求追踪客户。有些复杂的网络应用需要在不同的网页之间保持一致，它们需要这种会话状态的保持能力。

浏览器与 Web 服务器通过 HTTP 协议进行通讯，而 Cookie 就是保存在 HTTP 协议的请求或者应答头部（在 HTTP 协议中，数据包括两部分，一部分是头部，由一些名值对构成，用来描述要被传输数据的一些信息。一部分是主体 (body)，是真正的数据（如 HTML 页面等））进行传送的。

在 HTML 文档被发送之前，Web 服务器通过传送 HTTP 包头中的 Set-Cookie 消息把一个 cookie 发送到用户的浏览器中。下面是一个遵循 Netscape cookie 草案的完整的 Set-Cookie 头：

Set-Cookie：customer=huangxp; path=/foo; domain=.ibm.com;
expires= Wednesday, 19-OCT-05 23:12:40 GMT; [secure]
Set-Cookie 的每个属性解释如下：

Customer=huangxp 一个"名称＝值"对，把名称 customer 设置为值"huangxp"，这个属性在 Cookie 中必须有。
path=/foo 控制哪些访问能够触发 cookie 的发送。如果没有指定 path，cookie 会在所有对此站点的 HTTP 传送时发送。如果 path=/directory，只有访问 /directory 下面的网页时，cookie 才被发送。在这个例子中，用户在访问目录 /foo 下的内容时，浏览器将发送此 cookie。如果指定了 path，但是 path 与当前访问的 url 不符，则此 cookie 将被忽略。
domain=.ibm.com 指定 cookie 被发送到哪台计算机上。正常情况下，cookie 只被送回最初向用户发送 cookie 的计算机。在这个例子中，cookie 会被发送到任何在 .ibm.com 域中的主机。如果 domain 被设为空，domain 就被设置为和提供 cookie 的 Web 服务器相同。如果 domain 不为空，并且它的值又和提供 cookie 的 Web 服务器域名不符，这个 Cookie 将被忽略。
expires= Wednesday, 19-OCT-05 23:12:40 GMT 指定 cookie 失效的时间。如果没有指定失效时间，这个 cookie 就不会被写入计算机的硬盘上，并且只持续到这次会话结束。
secure 如果 secure 这个词被作为 Set-Cookie 头的一部分，那么 cookie 只能通过安全通道传输（目前即 SSL 通道）。否则，浏览器将忽略此 Cookie。
一旦浏览器接收了 cookie，这个 cookie 和对远端 Web 服务器的连续请求将一起被浏览器发送。例如 前一个 cookie 被存入浏览器并且浏览器试图请求 URL http://www.ibm.com/foo/index.html 时，下面的 HTTP 包头就被发送到远端的 Web 服务器。

GET /foo/index.html HTTP/1.0
Cookie：customer=huangxp

一次典型的网络浏览过程
在了解了 Cookie 协议的一些基本内容之后，让我们看看一次典型的网络浏览过程中浏览器如何识别和处理 Cookie：

浏览器对于 Web 服务器应答包头中 Cookie 的操作步骤：

1. 从 Web 服务器的应答包头中提取所有的 cookie。
2. 解析这些 cookie 的组成部分（名称，值，路径等等）。
3. 判定主机是否允许设置这些 cookie。允许的话，则把这些 Cookie 存储在本地。
   浏览器对 Web 服务器请求包头中所有的 Cookie 进行筛选的步骤：
4. 根据请求的 URL 和本地存储 cookie 的属性，判断那些 Cookie 能被发送给 Web 服务器。
5. 对于多个 cookie，判定发送的顺序。
6. 把需要发送的 Cookie 加入到请求 HTTP 包头中一起发送。