2. 一致性
2.1. 语法表示法
本规范使用 [RFC5234] 的 Augmented Backus-Naur Form (ABNF) 表示法, 并采用 [RFC7405] 中定义的字符串大小写敏感表示法扩展.
本规范还使用 Section 5.6.1 中定义的列表扩展, 该扩展允许使用 "#" 操作符紧凑地定义逗号分隔列表 (类似于 "*" 操作符表示重复的方式). Appendix A 展示了汇总语法, 其中所有列表操作符都已扩展为标准 ABNF 表示法.
按照约定, 以 "obs-" 为前缀的 ABNF 规则名表示出于历史原因保留的废弃语法规则.
以下核心规则通过引用纳入本文, 如 [RFC5234] Appendix B.1 所定义: ALPHA (字母), CR (回车), CRLF (CR LF), CTL (控制字符), DIGIT (十进制 0-9), DQUOTE (双引号), HEXDIG (十六进制 0-9/A-F/a-f), HTAB (水平制表符), LF (换行), OCTET (任意 8 位数据序列), SP (空格), 以及 VCHAR (任意可见 US-ASCII 字符).
Section 5.6 定义了若干用于字段值的通用语法组件.
本规范使用术语 "character","character encoding scheme","charset" 和 "protocol element", 其含义与 [RFC6365] 中定义相同.
2.2. 要求表示法
本文件中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 BCP 14 [RFC2119] [RFC8174] 中的描述解释, 但仅当它们以此处所示全大写形式出现时才具有该含义.
本规范根据 HTTP 通信参与者的角色来规定一致性准则. 因此, 要求会施加于发送方, 接收方, 客户端, 服务器, 用户代理, 中介, 源服务器, 代理, 网关或缓存, 具体取决于该要求所约束的行为. 当要求适用于单次通信范围之外时, 还会对实现, 资源所有者和协议元素注册施加额外要求.
当某项要求仅适用于创建协议元素的实现, 而不是适用于将收到元素向下游转发的实现时, 本文使用动词 "generate" 而不是 "send".
如果某实现遵守与其在 HTTP 中承担的角色相关的所有要求, 则认为该实现是一致的.
发送方不得生成不匹配相应 ABNF 规则所定义语法的协议元素. 在给定消息内, 发送方不得生成只允许其他角色参与者生成的协议元素或语法替代形式 (即发送方在该消息中不具备的角色).
HTTP 一致性既包括符合正在使用的协议版本的特定消息语法, 也包括符合所发送协议元素的语义. 例如, 一个声称符合 HTTP/1.1 但无法识别 HTTP/1.1 接收方所需特性的客户端, 将无法与根据这些声明调整响应的服务器互操作. 反映用户选择的特性, 如内容协商和用户选择的扩展, 可能影响协议流之外的应用行为; 发送不能准确反映用户选择的协议元素会使用户困惑并妨碍选择.
当某实现不符合语义一致性时, 该实现消息的接收方最终会开发变通方法来相应调整自身行为. 如果这些变通方法仅限于有问题的实现, 接收方可以采用这些变通方法并仍然符合本协议. 例如, 服务器常会扫描 User-Agent 字段值的一部分, 用户代理也常会扫描 Server 字段值, 以便针对已知缺陷或选择不佳的默认值调整自身行为.
2.3. 长度要求
接收方应以防御方式解析收到的协议元素, 仅对该元素符合其 ABNF 语法并能放入合理缓冲区大小抱有有限预期.
HTTP 对其许多协议元素没有具体长度限制, 因为适当长度会随着部署上下文和实现目的而大幅变化. 因此, 发送方和接收方之间的互操作性取决于双方对每个协议元素合理长度的共同预期. 此外, 在过去三十多年 HTTP 使用过程中, 某些协议元素通常被认为合理的长度已经发生变化, 并预计未来还会继续变化.
至少, 接收方必须能够解析和处理协议元素长度, 其长度至少应达到它在其他消息中为相同协议元素所生成值的长度. 例如, 发布指向自身资源的很长 URI 引用的源服务器, 需要能够在这些引用作为目标 URI 被接收时解析并处理它们.
许多收到的协议元素只会被解析到足以识别该元素并将其向下游转发的程度. 例如, 中介可能会把收到的字段解析为字段名和字段值组件, 随后在不进一步解析字段值内部内容的情况下转发该字段.
2.4. 错误处理
接收方必须根据本规范为收到的协议元素定义的语义解释该元素, 包括本规范的扩展, 除非接收方已经 (通过经验或配置) 判定发送方错误地实现了这些语义所隐含的行为. 例如, 如果检查 User-Agent 头字段表明某个具体实现版本在收到某些内容编码时已知会失败, 源服务器可以忽略收到的 Accept-Encoding 头字段内容.
除非另有说明, 接收方可以尝试从无效构造中恢复可用的协议元素. 除非错误处理会直接影响安全性, HTTP 不定义具体错误处理机制, 因为协议的不同应用需要不同的错误处理策略. 例如, Web 浏览器可能希望从 Location 头字段不符合 ABNF 的响应中透明恢复, 而系统控制客户端可能认为任何形式的错误恢复都是危险的.
如 Section 9.2.2 所述, 当底层连接失败时, 某些请求可以由客户端自动重试.
2.5. 协议版本
HTTP 的版本号由两个十进制数字组成, 中间以 "." (句点或小数点) 分隔. 第一个数字 (主版本) 表示消息语法, 第二个数字 (次版本) 表示发送方所符合的该主版本内最高次版本 (即能够理解以便未来通信).
虽然 HTTP 的核心语义在协议版本之间不会变化, 但它们在 "线上" 的表达方式可能变化, 因此当线上格式发生不兼容变更时, HTTP 版本号也会变化. 此外, HTTP 允许通过已定义的扩展点 (Section 16) 对协议进行增量的向后兼容变更, 而无需改变其版本号.
协议版本整体表示发送方符合该版本对应规范中列出的要求集合. 例如, 版本 "HTTP/1.1" 由本文档,"HTTP Caching" [CACHING] 和 "HTTP/1.1" [HTTP/1.1] 的组合规范定义.
当引入不兼容的消息语法时, HTTP 的主版本号递增. 当对协议所做变更具有增加消息语义或暗示发送方具备额外能力的效果时, 次版本号递增.
即使发送方只使用协议的向后兼容子集, 次版本也会宣告发送方的通信能力, 从而让接收方知道可在响应中 (对服务器而言) 或未来请求中 (对客户端而言) 使用更高级的特性.