Appendix B. Changes from RFC 2616 (相对于RFC 2616的变更)

本版本的主要变更是编辑性质的: 提取消息语法并将HTTP语义划分为核心功能、条件请求、部分请求、缓存和认证的独立文档。一致性语言已被修订以明确针对需求，术语已得到改进以区分有效载荷与表示，以及表示与资源。

添加了一个新要求，即当URI中嵌入的语义与请求方法不一致时，应禁用这些语义，因为这是互操作性失败的常见原因。(第2节)

添加了一个算法，用于确定有效载荷是否与特定标识符相关联。(第3.1.4.1节)

文本媒体类型的默认字符集ISO-8859-1已被删除; 现在默认值是媒体类型定义所说的内容。同样，Accept-Charset头字段对ISO-8859-1的特殊处理也已删除。(第3.1.1.3节和第5.3.3节)

Content-Location的定义已更改为不再影响用于解析相对URI引用的基URI，这是由于实现支持不佳以及可能破坏内容协商资源中的相对链接的不良影响。(第3.1.4.2节)

为了与[RFC7230]的方法中立解析算法保持一致，GET的定义已放宽，使请求可以有主体，即使主体对GET没有意义。(第4.3.1节)

服务器不再需要处理所有Content-*头字段，并且在PUT请求中明确禁止使用Content-Range。(第4.3.4节)

CONNECT方法的定义已从[RFC2817]移至本规范。(第4.3.6节)

OPTIONS和TRACE请求方法已被定义为安全的。(第4.3.7节和第4.3.8节)

由于广泛部署的损坏实现，Expect头字段的扩展机制已被删除。(第5.1.1节)

Max-Forwards头字段已被限制为OPTIONS和TRACE方法; 以前，扩展方法也可以使用它。(第5.1.2节)

当没有引用URI适用时，已建议将"about:blank" URI用作Referer头字段的值，这将该情况与Referer字段未发送或已被删除的其他情况区分开来。(第5.5.2节)

以下状态码现在可缓存(即，它们可以由缓存存储和重用，而无需存在显式的新鲜度信息): 204、404、405、414、501。(第6节)

201(Created)状态描述已更改为允许创建多个资源的可能性。(第6.3.2节)

203(Non-Authoritative Information)的定义已扩展为也包括有效载荷转换的情况。(第6.3.4节)

可以安全自动重定向的请求方法集不再封闭; 用户代理能够根据请求方法语义做出该判断。重定向状态码301、302和307不再对响应有效载荷和用户交互有规范性要求。(第6.4节)

状态码301和302已更改为允许用户代理将方法从POST重写为GET。(第6.4.2节和第6.4.3节)

303(See Other)状态码的描述已更改为允许在给出显式新鲜度信息的情况下缓存它，并且为对GET的303响应添加了特定定义。(第6.4.4节)

由于有关代理的带内配置的安全问题，305(Use Proxy)状态码已被弃用。(第6.4.5节)

400(Bad Request)状态码已放宽，使其不限于语法错误。(第6.5.1节)

426(Upgrade Required)状态码已从[RFC2817]中并入。(第6.5.15节)

关于HTTP-date和Date头字段的要求目标已减少到生成日期的系统，而不是所有发送日期的系统。(第7.1.1节)

Location头字段的语法已更改为允许所有URI引用，包括相对引用和片段，以及关于何时使用片段不合适的一些说明。(第7.1.2节)

Allow已被重新分类为响应头字段，删除了在PUT请求中指定它的选项。与Allow内容相关的要求已放宽; 相应地，客户端不需要始终信任其值。(第7.4.1节)

已定义了方法注册表。(第8.1节)

状态码注册表已由本规范重新定义; 以前，它在[RFC2817]的第7.1节中定义。(第8.2节)

内容编码的注册已更改为需要IETF审查。(第8.4节)

Content-Disposition头字段已被删除，因为它现在由[RFC6266]定义。

Content-MD5头字段已被删除，因为它在部分响应方面的实现不一致。