引言

HTTP（Hypertext Transfer Protocol，超文本传输协议[插图]）是在万维网上进行通信时所使用的协议方案。HTTP有很多应用，但最著名的是用于Web浏览器和Web服务器之间的双工通信。

《HTTP权威指南》一书将HTTP中一些互相关联且常被误解的规则梳理清楚，并编写了一系列基于各种主题的章节介绍HTTP各方面的特性。纵观全书，对HTTP“为什么”这样做进行了详细的解释，而不仅仅停留在它是“怎么做”的。此外，这本书还介绍了很多HTTP应用程序正常工作所必需且重要的非HTTP技术。

这本书主要包括以下内容：

• 第一部分描述了Web的基础构件与HTTP的核心技术
• 第二部分重点介绍了Web系统的结构构造块：HTTP服务器、代理、缓存、网关以及机器人应用程序。
• 第三部分提供了一套用于追踪身份、增强安全性以及控制内容访问的技术和技巧。
• 第四部分涵盖HTTP报文主体和Web标准，前者包含实际内容，后者描述并处理主体内容。
• 第五部分介绍了发布和传播Web内容的技巧。
• 第六部分是一些很有用的参考附录，以及相关技术的教程。

客户端识别与cookie机制

Web服务器可能会同时与数千个不同的客户端进行对话。这些服务器通常要记录下它们在与谁交谈，而不会认为所有的请求都来自匿名的客户端。

cookie与会话跟踪

电子商务Web站点用会话cookie在用户浏览时记录下用户的购物车信息。我们以流行的购物网站Amazon.com为例。在浏览器中输入网站地址时，就启动了一个事务链，在这些事务中Web服务器会通过一系列的重定向、URL重写以及cookie设置来附加标识信息。

过程如下：

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

cookie与缓存

缓存那些与cookie事务有关的文档时要特别小心。你不会希望给用户分配一个过去某些用户用过的cookie，或者更糟糕的是，向一个用户展示其他人私有文档的内容。

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

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

文档的所有者最清楚文档是否是不可缓存的。如果文档不可缓存，就显式地注明——具体来说，如果除了Set-Cookie首部之外文档是可缓存的，就使用Cache-Control:no-cache="Set-Cookie"。另一种更通用的做法是为可缓存文档使用Cache-Control:public，这样有助于节省Web中的带宽。

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

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

有些缓存在将响应缓存起来之前会删除Set-Cookie首部，但这样也会引发一些问题，因为在没有缓存的时候，通常都会有cookie贴在客户端上，但由缓存提供服务的客户端就不会有cookie了。强制缓存与原始服务器重新验证每条请求，并将返回的所有Set-Cookie首部都合并到客户端的响应中去，就可以改善这种状况。原始服务器可以通过向缓存的副本中添加这个首部来要求进行这种再验证：

Cache-Control: must-revalidate, max-age=0

即便内容实际上是可以缓存的，比较保守的缓存可能也会拒绝缓存所有包含Set-Cookie首部的响应。有些缓存允许使用缓存Set-Cookie图片，但不缓存文本的模式。

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

带有Cookie首部的请求到达时，就在提示我们，得到的结果可能是私有的。一定要将私有内容标识为不可缓存的，但有些服务器可能会犯错，没有将此内容标记为不可缓存的。

有些响应文档对应于携带Cookie首部的请求，保守的缓存可能会选择不去缓存这些响应文档。同样，有些缓存允许使用缓存cookie图片，而不缓存文本的模式。得到更广泛接受的策略是缓存带有Cookie首部的图片，将过期时间设置为零，强制每次都进行再验证。

cookie、安全性和隐私

cookie是可以禁止的，而且可以通过日志分析或其他方式来实现大部分跟踪记录，所以cookie自身并不是很大的安全隐患。实际上，可以通过提供一个标准的审查方法在远程数据库中保存个人信息，并将匿名cookie作为键值，来降低客户端到服务器的敏感数据传送频率。

但是，潜在的滥用情况总是存在的，所以，在处理隐私和用户跟踪信息时，最好还是要小心一些。第三方Web站点使用持久cookie来跟踪用户就是一种最大的滥用。将这种做法与IP地址和Referer首部信息结合在一起，这些营销公司就可以构建起相当精确的用户档案和浏览模式信息。

尽管有这么多负面的宣传，人们通常还是认为，如果能够小心地确认在向谁提供私人信息，并仔细查阅站点的隐私政策，那么，cookie会话处理和事务处理所带来的便利性要比大部分风险更重要。

1998年，计算机事故咨询能力组织（Computer Incident Advisory Capability）（美国能源部的一部分）编写了一份过分使用cookie的风险评估报告。下面是那份报告的摘要。

• 问题cookie是Web服务器用来识别Web用户的小块数据。关于cookie功能的流行说法和谣言之间的比例已经达到了令人不解的地步，使用户恐惧，使管理者忧心。
• 脆弱性评估由于使用Web浏览器cookie使得系统被破坏或窃听，从而带来的系统脆弱性本质上并不存在。cookie只能告知Web服务器你以前是否到过某个网站，并在下次访问时将来自Web服务器的一些短小信息（比如用户编码）回送给它。大部分cookie只会持续到用户退出浏览器为止，然后就会被破坏掉。第二种名为持久cookie的cookie有一个过期日期，会在你的硬盘上存储到那个日期为止。无论用户何时返回一个站点，都可以通过持久cookie来识别其身份，以便跟踪用户的浏览习惯。你来自何处，以及访问过哪些Web页面等信息已经存储在Web服务器的日志文件中了，也可以用这些信息来跟踪用户的浏览习惯，只是使用cookie更简单一些罢了。

总结

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

处理缓存时需要一些指导性规则，避免信息泄露。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。