Appendix C. Changes from Previous RFCs (与之前RFC的变更)

C.1. Changes from HTTP/0.9 (从HTTP/0.9的变更)

由于 HTTP/0.9 不支持请求中的头字段，因此它没有支持基于名称的虚拟主机（通过检查 Host 头字段选择资源）的机制。任何实现基于名称的虚拟主机的服务器都应该禁用对 HTTP/0.9 的支持。大多数看起来像 HTTP/0.9 的请求实际上是构造不当的 HTTP/1.x 请求，这是由于客户端未能正确编码请求目标而引起的。

C.2. Changes from HTTP/1.0 (从HTTP/1.0的变更)

C.2.1. Multihomed Web Servers (多宿主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 Connections (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. Introduction of Transfer-Encoding (引入Transfer-Encoding)

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

C.3. Changes from RFC 7230 (从RFC 7230的变更)

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

在内容之外禁止使用裸 CR。（第 2.2 节）

authority-form 的 ABNF 定义已从 URI 的更通用的权限组件（其中端口是可选的）更改为 CONNECT 所需的特定 host:port 格式。（第 3.2.3 节）

要求接收方在处理模糊的消息帧时避免走私/拆分攻击。（第 6.1 节）

在分块扩展的 ABNF 中，";" 和 "=" 周围的（不良）空格已重新引入。空格在 [RFC7230] 中被删除，但发现该更改破坏了现有实现。（第 7.1.1 节）

尾部字段语义现在超越了分块传输编码的细节。分块的解码算法（第 7.1.3 节）已更新，以鼓励将尾部字段与头部分分开存储/转发，仅在接收方知道相应的字段定义允许并定义如何合并时才允许合并到头部分，否则丢弃尾部字段而不是合并。尾部部分现在称为尾部部分，以便与头部分更一致，并与正文部分更加区分。（第 7.1.2 节）

不允许使用名为 "q" 的传输编码参数，以避免与 TE 头字段中使用的排名冲突。（第 7.3 节）

---