引言

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

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

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

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

Web机器人

Web机器人是能够在无需人类干预的情况下自动进行一系列Web事务处理的软件程序。很多机器人会从一个Web站点逛到另一个Web站点，获取内容，跟踪超链，并对它们找到的数据进行处理。根据这些机器人自动探查Web站点的方式，人们为它们起了一些各具特色的名字，比如“爬虫”、“蜘蛛”、“蠕虫”以及“机器人”等，就好像它们都有自己的头脑一样。

机器人的HTTP

很多机器人都试图只实现请求它们所查找内容所需的最小HTTP集。这会引发一些问题；但短期内这种行为不会发生什么改变。结果就是，很多机器人发出的都是HTTP/1.0请求，因为这个协议的要求很少。

识别请求首部

尽管机器人倾向于只支持最小的HTTP集，但大部分机器人确实实现并发送了一些识别首部——最值得一提的就是User-Agent首部。建议机器人实现者们发送一些基本的首部信息，以通知各站点机器人的能力、机器人的标识符，以及它是从何处起源的。

在追踪错误爬虫的所有者，以及向服务器提供机器人所能处理的内容类型时，这些信息都是很有用的。鼓励机器人实现者们使用的基本识别首部包括如下内容。

• User-Agent：将发起请求的机器人名字告知服务器。
• From：提供机器人的用户/管理者的E-mail地址。
• Accept：告知服务器可以发送哪些媒体类型。[插图]这有助于确保机器人只接收它感兴趣的内容（文本、图片等）。
• Referer：提供包含了当前请求URL的文档的URL。

虚拟主机

机器人实现者要支持Host首部。随着虚拟主机的流行，请求中不包含Host首部的话，可能会使机器人将错误的内容与一个特定的URL关联起来。因此，HTTP/1.1要求使用Host首部。

在默认情况下，大多数服务器都被配置为提供一个特定的站点。因此，不包含Host首部的爬虫向提供两个站点的服务器发起请求时，假设默认情况下服务器被配置为提供www.joes-hardware.com站点（且不需要Host首部），那么，若请求www.foo.com上的某个页面，爬虫实际获取的就是Joe的五金商店的站点上的内容。更糟糕的是，爬虫会认为来自Joe的五金站点上的那些内容是来自www.foo.com的。如果带有相对立的政治色彩或其他观点的两个站点是由同一台服务器提供的，你肯定能想象到会有更不幸的局面出现。

条件请求

鉴于这些机器人的努力程度，尽量减少机器人所要获取内容的数量通常是很有意义的。对因特网搜索引擎机器人来说，需要下载的潜在页面有数十亿，所以，只在内容发生变化时才重新获取内容是很有意义的。

有些机器人实现了条件HTTP请求，它们会对时间戳或实体标签进行比较，看看它们最近获取的版本是否已经升级了。这与HTTP缓存查看已获取资源的本地副本是否有效的方法非常相似。

对响应的处理

很多机器人的兴趣主要在于用简单的GET方法来获取所请求的内容，所以，一般不会在处理响应的方式上花费太多时间。但是，使用了某些HTTP特性（比如条件请求）的机器人，以及那些想要更好地探索服务器，并与服务器进行交互的机器人则要能够对各种不同类型的HTTP响应进行处理。

1．状态码

总之，机器人至少应该能够处理一些常见的，以及预期的状态码。所有机器人都应该理解200 OK和404 Not Found这样的状态码。它们还应该能够根据响应的一般类别对它并不十分理解的状态码进行处理。第3章的表3-2给出了不同状态码的分类及其含义。有些服务器并不总能返回适当的错误代码，认识到这一点是很重要的。有些服务器甚至会将HTTP状态码200 OK与描述错误状态的报文主体文本一同返回！很难对此做些什么——只是实现者应该要了解这些情况。

2．实体除了HTTP首部所嵌的信息之外，机器人也会在实体中查找信息。HTML元标签，比如元标签http-equiv，就是内容编写者用于嵌入资源附加信息的一种方式。

服务器可能会为它所处理的内容提供一些首部，标签http-equiv为内容编写者提供了一种覆盖这些首部的方式：

<meta http-equiv="Refresh" content="1; URL=index.html">

这个标签会指示接收者处理这个文档时，要当作其HTTP响应首部中有一个值为1,URL=index.html的Refresh HTTP首部。

有些服务器实际上会在发送HTML页面之前先对其内容进行解析，并将http-equiv指令作为首部包含进去；有些服务器则不会。机器人实现者可能会去扫描HTML文档的HEAD组件，以查找http-equiv信息。

User-Agent导向

Web管理者应该记住，会有很多的机器人来访问它们的站点，因此要做好接收机器人请求的准备。很多站点会为不同的用户代理进行内容优化，并尝试着对浏览器类型进行检测，以确保能够支持各种站点特性。这样的话，当实际的HTTP客户端根本不是浏览器，而是机器人的时候，站点为机器人提供的就会是出错页面而不是页面内容了。在某些搜索引擎上执行文本搜索，搜索短语“your browser does not support frames”（你的浏览器不支持框架），会生成一个包含那条短语的出错页面列表。

站点管理者应该设计一个处理机器人请求的策略。比如，它们可以为所有其他特性不太丰富的浏览器和机器人开发一些页面，而不是将其内容限定在特定浏览器所支持的范围。至少，管理者应该知道机器人是会访问其站点的，不应该在机器人访问时感到猝不及防。

总结

机器人和所有其他HTTP客户端程序并没有什么区别。它们也要遵守HTTP规范中的规则。发出HTTP请求并将自己广播成HTTP/1.1客户端的机器人也要使用正确的HTTP请求首部。

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