引言

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

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

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

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

摘要认证

基本认证便捷灵活，但极不安全。用户名和密码都是以明文形式传送的，也没有采取任何措施防止对报文的篡改。安全使用基本认证的唯一方式就是将其与SSL配合使用。

增强保护质量

可以在三种摘要首部中提供qop字段：WWW-Authenticate、Authorization和Authentication-Info。

通过qop字段，客户端和服务器可以对不同类型及质量的保护进行协商。比如，即便会严重降低传输速度，有些事务可能也要检查报文主体的完整性。

服务器首先在WWW-Authenticate首部输出由逗号分隔的qop选项列表。然后客户端从中选择一个它支持且满足其需求的选项，并将其放在Authorization的qop字段中回送给服务器。

qop字段是可选的，但只是在后向兼容原有RFC 2069规范的情况下才是可选的。现代所有的摘要实现都应该支持qop选项。

报文完整性保护

如果使用了完整性保护（qop="auth-int"）, H（实体的主体部分）就是对实体主体部分，而不是报文主体部分的散列。对于发送者，要在应用任意传输编码方式之前计算；而对于接收者，则应在去除所有传输编码之后计算。注意，对于任何含有多部份的内容类型来说，多部分的边界和每部分中嵌入的首部都要包含在内。

摘要认证首部

基本认证和摘要认证协议都包含了WWW-Authenticate首部承载的授权质询、Authorization首部承载的授权响应。摘要认证还添加了可选的Authorization-Info首部，这个首部是在成功认证之后发送的，用于实现三步握手机制，并传送下一个随机数。

应该考虑的实际问题

多重质询

服务器可以对某个资源发起多重质询。比如，如果服务器不了解客户端的能力，就可以既提供基本认证质询，又提供摘要认证质询。客户端面对多重质询时，必须以它所支持的最强的质询机制来应答。

质询自身可能会包含由逗号分隔的认证参数列表。如果WWW-Authenticate或Proxy-Authenticate首部包含了多个质询，或者提供了多个WWW-Authenticate首部，用户Agent代理在解析WWW-Authenticate或Proxy-Authenticate首部字段值时就要特别小心。注意，很多浏览器只支持基本认证，要求这是提交给它的第一种认证机制。

在提供了认证选项范围的情况下，安全问题上就会存在明显的“最薄弱环节”。只有当基本认证是最低可接受认证方式时，服务器才应该包含它，而且管理员还应该警告用户，即使运行了不同层次安全措施，系统间使用相同密码也存在一定危险性。

差错处理

在摘要认证中，如果某个指令或其值使用不当，或者缺少某个必要指令，就应该使用响应400 Bad Request。

如果请求的摘要不匹配，就应该记录一次登录失败。某客户端连续多次失败可能说明有攻击者正在猜测密码。

认证服务器一定要确保URI指令指定的资源与请求行中指定的资源相同。如果不同，服务器就应该返回400 Bad Request错误。（这可能是一种攻击的迹象，因此服务器设计者可能会考虑将此类错误记录下来。）这个字段包含的内容与请求URL中的内容是重复的，用来应对中间代理可能对客户端请求进行的修改。这个经过修改（但估计语义是等价的）的请求计算后得到的摘要可能会与客户端计算出的摘要有所不同。

保护空间

域值，与被访问服务器的标准根URL结合在一起，定义了保护空间。

通过域可以将服务器上的受保护资源划分为一组保护空间，每个空间都有自己的认证机制和/或授权数据库。域值是一个字符串，通常由原始服务器分配，可能会有认证方案特有的附加语义。注意，可能会有多个授权方案相同，而域不同的质询。

保护空间确定了可以自动应用证书的区域。如果前面的某条请求已被授权，在一段时间内，该保护空间中所有其他请求都可以重用同一个证书，时间的长短由认证方案、参数和/或用户喜好来决定。除非认证方案进行了其他定义，否则单个保护空间是不能扩展到其服务器范围之外的。

对保护空间的具体计算取决于认证机制。

• 在基本认证中，客户端会假定请求URI中或其下的所有路径都与当前的质询处于同一个保护空间内。客户端可以预先提交对此空间中资源的认证，无需等待来自服务器的另一条质询。
• 在摘要认证中，质询的WWW-Authenticate:domain字段对保护空间作了更精确的定义。domain字段是一个用引号括起来的、中间由空格分隔的URI列表。通常认为，domain列表中的所有URI和逻辑上处于这些前缀之下的所有URI，都位于同一个保护空间中。如果没有domain字段，或者此字段为空，质询服务器上的所有URI就都在保护空间内。

重写URI

代理可以通过改变URI语法，而不改变所描述的实际资源的方式来重写URI。比如：

• 可以对主机名进行标准化，或用IP地址来取代；
• 可以用“%”转义形式来取代嵌入的字符；
• 如果某类型的一些附加属性不会影响从特定原始服务器上获取资源，就可以将其附加或插入到URI中。代理可修改URI，而且摘要认证会检查URI值的完整性，所以如果进行了任意一种修改，摘要认证就会被破坏。

缓存

共享的缓存收到包含Authorization首部的请求和转接那条请求产生的响应时，除非响应中提供了下列两种Cache-Control指令之一，否则一定不能将那条响应作为对任何其他请求的应答使用。

• 如果原始响应中包含有Cache-Control指令must-revalidate，缓存可以在应答后继请求时使用那条响应的实体部分。但它首先要用新请求的请求首部，与原始服务器再次进行验证，这样原始服务器就可以对新请求进行认证了。
• 如果原始响应中包含有Cache-Control指令public，在对任意后继请求的应答中都可以返回响应的实体部分。

总结

RFC 2617定义了两种保护质量的初始值：表示认证的auth，带有报文完整性保护的认证auth-int。将来可能还会出现其他qop选项。

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