1. 引言

指定新的 HTTP header 和 trailer 字段的语法是一项繁重工作. 即使有 [RFC7231] Section 8.3.1 的指导, 潜在的 HTTP 字段作者仍需面对许多决策和陷阱.

一旦字段被定义, 通常还需要编写定制的 parser 和 serializer, 因为每个字段值对看似通用的语法都有略微不同的处理方式.

本文档引入一组通用数据结构, 用于定义新的 HTTP 字段值, 以解决这些问题. 具体而言, 它为这些结构定义了一个通用的抽象模型, 并定义了一种具体序列化形式, 用于在 HTTP [RFC7230] header 和 trailer 字段中表达该模型.

如果某个 HTTP 字段被定义为 "Structured Header" 或 "Structured Trailer" (如果该字段二者皆可, 则称为 "Structured Field"), 它会使用本规范定义的类型来定义其语法和基本处理规则, 从而简化规范作者对它的定义, 也简化实现对它的处理.

此外, HTTP 的未来版本可以为这些结构的抽象模型定义替代序列化形式, 使使用该模型的字段无需重新定义即可更高效地传输.

注意, 本文档的目标不是重新定义现有 HTTP 字段的语法. 本文描述的机制仅意在供那些明确选择采用它们的字段使用.

Section 2 描述如何指定 Structured Field.

Section 3 定义若干可用于 Structured Fields 的抽象数据类型.

这些抽象类型可使用 Section 4 中描述的算法序列化为 HTTP 字段值, 也可从 HTTP 字段值中解析出来.

1.1. 有意严格的处理

本规范有意使用逐步算法定义严格的解析和序列化行为. 唯一定义的错误处理方式是使整个操作失败.

这种设计旨在鼓励忠实实现和良好互操作性. 因此, 如果某个实现试图通过更宽容地接受输入来提供帮助, 反而会损害互操作性, 因为这会迫使其他实现也实现类似 (但很可能存在细微差异) 的 workaround.

换言之, 严格处理是本规范有意提供的特性. 它允许生产者及早发现并修正不符合规范的输入, 并避免原本可能产生的互操作性和安全问题.

注意, 由于这种严格性, 如果某个字段由多方追加 (例如 intermediaries 或发送方中的不同组件), 其中一方的值存在错误很可能导致整个字段值解析失败.

1.2. 记法约定

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 在且仅在以此处所示全大写形式出现时, 应按 BCP 14 [RFC2119] [RFC8174] 中的描述解释.

本文档使用算法指定解析和序列化行为, 并使用 [RFC5234] 的 Augmented Backus-Naur Form (ABNF) 记法来说明 HTTP header 字段中的预期语法. 为此, 它使用 [RFC5234] 中的 VCHAR, SP, DIGIT, ALPHA 和 DQUOTE 规则. 它还包含 [RFC7230] 中的 tchar 和 OWS 规则.

从 HTTP 字段解析时, 实现的行为 MUST 与遵循这些算法无法区分. 如果解析算法与 ABNF 之间存在分歧, 以指定的算法为准.

对于序列化为 HTTP 字段, ABNF 说明其预期的线上表示, 算法则定义生成这些表示的推荐方式. 只要输出仍可被 Section 4.2 中描述的解析算法正确处理, 实现 MAY 偏离指定行为.