Appendix C. 相对先前 RFC 的变更

C.1. 相对 HTTP/0.9 的变更

由于 HTTP/0.9 不支持请求中的头字段, 因此它没有机制支持基于名称的虚拟主机 (通过检查 Host 头字段来选择资源). 任何实现基于名称的虚拟主机的服务器都应当禁用对 HTTP/0.9 的支持. 大多数看起来像 HTTP/0.9 的请求, 实际上是由于客户端未能正确编码 request-target 而造成的格式错误的 HTTP/1.x 请求.

C.2. 相对 HTTP/1.0 的变更

C.2.1. 多宿主 Web 服务器

客户端和服务器支持 Host 头字段 ([HTTP] 第 7.2 节), 在 HTTP/1.1 请求缺失该字段时报错, 以及接受绝对 URI (第 3.2 节) 的要求, 属于 HTTP/1.1 定义的最重要变更.

较旧的 HTTP/1.0 客户端假定 IP 地址与服务器之间存在一对一关系; 除了请求所指向的 IP 地址之外, 当时没有已建立的机制来区分请求意图到达的服务器. Host 头字段是在 HTTP/1.1 开发期间引入的, 尽管它很快被大多数 HTTP/1.0 浏览器实现, 仍然对所有 HTTP/1.1 请求施加了额外要求, 以确保其被完全采用. 在撰写本文时, 大多数基于 HTTP 的服务都依赖 Host 头字段来定位请求.

C.2.2. Keep-Alive 连接

在 HTTP/1.0 中, 每个连接都由客户端在请求之前建立, 并由服务器在发送响应后关闭. 然而, 一些实现实现了 [RFC2068] 第 19.7.1 节所述的显式协商 ("Keep-Alive") 版本的持久连接.

某些客户端和服务器可能希望通过 "Connection: keep-alive" 请求头字段显式协商, 以兼容这些早期持久连接方式. 然而, HTTP/1.0 持久连接的一些实验性实现存在缺陷; 例如, 如果 HTTP/1.0 代理服务器不理解 Connection, 它会错误地将该头字段转发给下一个入站服务器, 这会导致连接挂起.

曾经尝试的一种解决方案是引入 Proxy-Connection 头字段, 专门面向代理. 实践中, 这同样不可行, 因为代理经常以多层方式部署, 从而带来上文讨论的相同问题.

因此, 鼓励客户端不要在任何请求中发送 Proxy-Connection 头字段.

也鼓励客户端谨慎考虑在请求中使用 "Connection: keep-alive"; 虽然它们可以借此与 HTTP/1.0 服务器启用持久连接, 使用它们的客户端需要监控连接是否出现 "挂起" 请求 (这表明客户端应当停止发送该头字段), 并且当使用代理时, 客户端完全不应使用此机制.

C.2.3. Transfer-Encoding 的引入

HTTP/1.1 引入了 Transfer-Encoding 头字段 (第 6.1 节). 在通过符合 MIME 的协议转发 HTTP 消息之前, 需要先解码传输编码.

C.3. 相对 RFC 7230 的变更

介绍 HTTP 设计目标, 历史, 架构, 一致性准则, 协议版本控制, URI, 消息路由和头字段的大多数章节已移至 [HTTP]. 本文档已缩减为仅包含 HTTP/1.1 特定的消息语法和连接管理要求.

已禁止在内容之外使用裸 CR. (第 2.2 节)

authority-form 的 ABNF 定义已从 URI 的更一般 authority 组成部分 (其中 port 是可选的) 改为 CONNECT 所要求的特定 host:port 格式. (第 3.2.3 节)

接收方在处理含糊的消息分帧时, 需要避免走私/拆分攻击. (第 6.1 节)

在 chunked 扩展的 ABNF 中, ";" 和 "=" 周围的 (不良) 空白已被重新引入. [RFC7230] 中曾移除此空白, 但后来发现该变更会破坏已有实现. (第 7.1.1 节)

trailer 字段语义现在超越了 chunked 传输编码的具体细节. chunked 的解码算法 (第 7.1.3 节) 已更新, 以鼓励将 trailer 字段与头部区段分开存储/转发, 仅在接收方知道对应字段定义允许合并并定义了如何合并时才允许合并到头部区段中, 否则丢弃 trailer 字段而不是合并. trailer part 现在称为 trailer section, 以便与 header section 更一致, 并更明确地区别于 body part. (第 7.1.2 节)

为避免与 TE 头字段中 ranks 的使用冲突, 名为 "q" 的传输编码参数不被允许. (第 7.3 节)