Mr.J-- HTTP学习笔记（十）-- Cookie机制

我的专栏： HTTP学习笔记

承载用户相关信息的HTTP首部

首部名称	首部类型	描述
From	请求	用户的 E-mail 地址
User-Agent	请求	用户的浏览器软件
Referer	请求	用户是从这个页面上依照链接跳转过来的
Authorization	请求	用户名和密码
Client-IP	扩展（请求）	客户端的 IP 地址
X-Forwarded-For	扩展（请求）	客户端的 IP 地址
Cookie	扩展（请求）	服务器产生的 ID 标签

cookie 是当前识别用户，实现持久会话的最好方式。

cookie的类型

会话 cookie ：会话 cookie 是一种临时 cookie，它记录了用户访问站点时的设置和偏好。用户退出浏览器时，会话cookie 就被删除了。

持久 cookie： 持久 cookie 的生存时间更长一些；它们存储在硬盘上，浏览器退出，计算机重启时它们仍然存在。通常会用持久 cookie 维护某个用户会周期性访问的站点的配置文件或登录名。

会话 cookie 和持久 cookie 之间唯一的区别就是它们的过期时间。如果设置了 Discard 参数，或者没有设置 Expires 或 Max-Age 参数来说明扩展的过期时间，这个 cookie 就是一个会话 cookie。

cookie是如何工作的

用户首次访问 Web 站点时， Web 服务器对用户一无所知。 Web 服务器希望这个用户会再次回来，所以想给这个用户“拍上” 一个独有的 cookie，这样以后它就可以识别出这个用户了。

cookie 中可以包含任意信息，但它们通常都只包含一个服务器为了进行跟踪而产生的独特的识别码。例如上面(c)中的id=34294。

cookie罐：客户端的状态

cookie 的基本思想就是让浏览器积累一组服务器特有的信息，每次访问服务器时都将这些信息提供给它。

微软Internet Explorer的cookie

Internet Explorer 中 cookie 文件格式是特有的，但很多字段都很容易理解。 cookie 一个接一个地存储在文件中，每
个 cookie 都由多行构成。文件中每个 cookie 的第一行中都包含了 cookie 的变量名。下一行是变量的值。第三行是域和路径。剩下的行就是一些特有的数据，可能包含日期和一些标记。

不同站点使用不同的cookie

浏览器内部的 cookie 罐中可以有成百上千个 cookie，但浏览器不会将每个 cookie都发送给所有的站点。实际上，它们通常只向每个站点发送 2 ～ 3 个 cookie。原因如下：

• 对所有这些 cookie 字节进行传输会严重降低性能。浏览器实际传输的 cookie 字节数要比实际的内容字节数多！
• cookie 中包含的是服务器特有的名值对，所以对大部分站点来说，大多数 cookie都只是无法识别的无用数据。
• 将所有的 cookie 发送给所有站点会引发潜在的隐私问题，那些你并不信任的站点也会获得你只想发给其他站点的信息。

cookie的域属性

产生 cookie 的服务器可以向 Set-Cookie 响应首部添加一个 Domain 属性来控制哪些站点可以看到那个 cookie。比如，下面的 HTTP 响应首部就是在告诉浏览器将cookie user="mary17" 发送给域 ".airtravelbargains.com" 中的所有站点：

Set-cookie: user="mary17"; domain="airtravelbargains.com"

cookie路径属性

cookie 规范甚至允许用户将 cookie 与部分 Web 站点关联起来。可以通过 Path 属性来实现这一功能，在这个属性列出的 URL 路径前缀下所有 cookie 都是有效的。
例如，某个 Web 服务器可能是由两个组织共享的，每个组织都有独立的 cookie。站点 www.airtravelbargains.com 可能会将部分 Web 站点用于汽车租赁——比如，http://www.airtravelbargains.com/autos/——用一个独立的 cookie 来记录用户喜欢的
汽车尺寸。可能会生成一个如下所示的特殊汽车租赁 cookie：

Set-cookie: pref=compact; domain="airtravelbargains.com"; path=/autos/

cookie成分

cookie 规范有两个不同的版本： cookies 版本 0（有时被称为 Netscapecookies）和 cookies 版本 1（RFC 2965）。 cookies 版本 1 是对 cookies 版本 0 的扩展。

cookie与会话跟踪

可以用 cookie 在用户与某个 Web 站点进行多项事务处理时对用户进行跟踪。

a——浏览器首次请求 Amazon.com 根页面。
b——服务器将客户端重定向到一个电子商务软件的 URL 上。
c——客户端对重定向的 URL 发起一个请求。
d——服务器在响应上贴上两个会话 cookie，并将用户重定向到另一个URL，这样客户端就会用这些附加的 cookie 再次发出请求。这个新的 URL 是个胖 URL，也就是说有些状态嵌入到 URL 中去了。如果客户端禁止了 cookie，只要用户一直跟随着 Amazon.com 产生的胖 URL 链接，不离开网站，仍然可以实现一些基本的标识功能。
e——客户端请求新的 URL，但现在会传送两个附加的 cookie。
f——服务器重定向到 home.html 页面，并附加另外两个 cookie。
g——客户端获取 home.html 页面并将所有四个 cookie 都发送出去。
h——服务器回送内容。

cookie与缓存

cookie 和缓存的规则并没有很好地建立起来。下面是处理缓存时的一些指导性规则。

• 如果无法缓存文档，要将其标示出来

文档的所有者最清楚文档是否是不可缓存的。如果文档不可缓存，就显式地注明——具体来说，如果除了 Set-Cookie 首部之外文档是可缓存的，就使用Cache-Control:no-cache="Set-Cookie"。

• 缓存 Set-Cookie 首部时要小心

如果响应中有 Set-Cookie 首部，就可以对主体进行缓存，但要特别注意对 Set-Cookie 首部的缓存。如果向多个用户发送了相同的Set-Cookie 首部，可能会破坏用户的定位。

• 小心处理带有 Cookie 首部的请求

带有 Cookie 首部的请求到达时，就在提示我们，得到的结果可能是私有的。有些响应文档对应于携带 Cookie 首部的请求，保守的缓存可能会选择不去缓存这些响应文档。

cookie、安全性和隐私

cookie 是可以禁止的，而且可以通过日志分析或其他方式来实现大部分跟踪记录，所以 cookie 自身并不是很大的安全隐患。

潜在的滥用情况总是存在的，所以，在处理隐私和用户跟踪信息时，最好还是要小心一些。第三方 Web 站点使用持久 cookie 来跟踪用户就是一种最大的滥用。