2. Conformance (一致性)

2.1. Syntax Notation (语法符号)

本规范使用 [RFC5234] 的增强巴科斯-瑙尔范式 (Augmented Backus-Naur Form, ABNF) 表示法, 并扩展了 [RFC7405] 中定义的字符串大小写敏感性表示法.

本规范还使用第5.6.1节中定义的列表扩展, 允许使用 "#" 运算符简洁地定义逗号分隔的列表 (类似于 "*" 运算符表示重复). 附录A显示了将所有列表运算符扩展为标准ABNF表示法的完整语法.

按照惯例, 以 "obs-" 为前缀的ABNF规则名称表示由于历史原因出现的过时语法规则.

以下核心规则通过引用包含在内, 如 [RFC5234] 附录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字符).

第5.6节定义了字段值的一些通用语法组件.

本规范使用 [RFC6365] 中定义的术语 "character" (字符)、"character encoding scheme" (字符编码方案)、"charset" (字符集) 和 "protocol element" (协议元素).

2.2. Requirements Notation (需求符号)

本文档中的关键词 "MUST" (必须)、"MUST NOT" (禁止)、"REQUIRED" (必需)、"SHALL" (应)、"SHALL NOT" (不应)、"SHOULD" (应该)、"SHOULD NOT" (不应该)、"RECOMMENDED" (推荐)、"NOT RECOMMENDED" (不推荐)、"MAY" (可以) 和 "OPTIONAL" (可选) 应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释, 当且仅当它们以全大写形式出现时, 如此处所示.

本规范根据HTTP通信中参与者的角色确定一致性标准. 因此, 根据需求所约束的行为, 将需求放在发送方 (Senders)、接收方 (Recipients)、客户端 (Clients)、服务器 (Servers)、用户代理 (User Agents)、中间人 (Intermediaries)、源服务器 (Origin Servers)、代理 (Proxies)、网关 (Gateways) 或缓存 (Caches) 上. 当需求适用于单个通信范围之外时, 还会对实现 (Implementations)、资源所有者 (Resource Owners) 和协议元素注册 (Protocol Element Registrations) 提出额外要求.

动词 "generate" (生成) 用于代替 "send" (发送), 表示需求仅适用于创建协议元素的实现, 而不是将接收到的元素向下游转发的实现.

如果实现符合其在HTTP中扮演的角色相关的所有需求, 则该实现被认为是一致的 (Conformant).

发送方禁止 (MUST NOT) 生成与相应ABNF规则定义的语法不匹配的协议元素. 在给定消息内, 发送方禁止 (MUST NOT) 生成仅允许由其他角色的参与者生成的协议元素或语法替代 (即, 发送方对于该消息不具有的角色).

对HTTP的一致性既包括对所使用协议版本的特定消息语法的一致性, 也包括对所发送协议元素语义的一致性. 例如, 声称符合HTTP/1.1但未能识别HTTP/1.1接收方所需功能的客户端将无法与根据这些声称调整其响应的服务器进行互操作. 反映用户选择的特性, 如内容协商 (Content Negotiation) 和用户选择的扩展, 可能会影响协议流之外的应用行为; 发送不准确反映用户选择的协议元素会使用户感到困惑并抑制选择.

当实现未能满足语义一致性时, 该实现消息的接收方最终会开发变通方法 (Workarounds) 来相应地调整其行为. 如果变通方法仅限于有问题的实现, 则接收方可以 (MAY) 采用此类变通方法, 同时仍然符合本协议. 例如, 服务器经常扫描User-Agent字段值的部分内容, 用户代理经常扫描Server字段值, 以调整它们自己的行为以应对已知的错误或选择不当的默认值.

2.3. Length Requirements (长度需求)

接收方应该 (SHOULD) 防御性地解析接收到的协议元素, 仅对元素符合其ABNF语法并适合合理缓冲区大小抱有边际期望.

HTTP对其许多协议元素没有特定的长度限制, 因为合适的长度会因部署上下文和实现目的而有很大差异. 因此, 发送方和接收方之间的互操作性取决于对每个协议元素什么是合理长度的共同期望. 此外, 对某些协议元素通常理解的合理长度在过去三十年的HTTP使用过程中已经发生了变化, 并且预计在未来会继续变化.

至少, 接收方必须 (MUST) 能够解析和处理协议元素长度, 该长度至少与它在其他消息中为这些相同协议元素生成的值一样长. 例如, 发布对其自己资源的非常长URI引用的源服务器需要能够解析和处理作为目标URI接收的那些相同引用.

许多接收到的协议元素仅被解析到识别和向下游转发该元素所需的程度. 例如, 中间人可能将接收到的字段解析为其字段名称和字段值组件, 但随后转发该字段而不在字段值内部进行进一步解析.

2.4. Error Handling (错误处理)

接收方必须 (MUST) 根据本规范为接收到的协议元素定义的语义 (包括本规范的扩展) 来解释该元素, 除非接收方已经 (通过经验或配置) 确定发送方错误地实现了这些语义所暗示的内容. 例如, 如果检查User-Agent头字段表明特定实现版本在接收某些内容编码时已知会失败, 则源服务器可能会忽略接收到的Accept-Encoding头字段的内容.

除非另有说明, 接收方可以 (MAY) 尝试从无效构造中恢复可用的协议元素. HTTP没有定义特定的错误处理机制, 除非它们对安全性有直接影响, 因为协议的不同应用需要不同的错误处理策略. 例如, Web浏览器可能希望从Location头字段不符合ABNF解析的响应中透明恢复, 而系统控制客户端可能认为任何形式的错误恢复都是危险的.

在底层连接失败的情况下, 客户端可以自动重试某些请求, 如第9.2.2节所述.

2.5. Protocol Version (协议版本)

HTTP的版本号由两个用 "." (句点或小数点) 分隔的十进制数字组成. 第一个数字 (主版本号, Major Version) 表示消息语法, 而第二个数字 (次版本号, Minor Version) 表示发送方符合该主版本内的最高次版本 (能够理解以便未来通信).

虽然HTTP的核心语义在协议版本之间不会改变, 但它们在"线路上"的表达可以改变, 因此当对线路格式进行不兼容的更改时, HTTP版本号会改变. 此外, HTTP允许在次版本号内进行增量的、向后兼容的更改, 以便向协议引入新功能而不破坏现有实现.

当实现向前兼容地支持主版本号内的未来次版本时, 发送方应该 (SHOULD) 仅发送它所声称支持的最高次版本号. 接收方必须 (MUST) 能够解析并理解该主版本号内任何更高次版本号的消息, 尽管某些功能可能不受支持.