跳到主要内容

1. 引言

HTTP 没有定义保护内容或表示的数据完整性的方法. 当 HTTP 消息在端点之间传输时, 较低层的特性或属性, 如 TCP 校验和或 TLS 记录 [TLS], 可以提供一定的完整性保护. 然而, 面向传输的完整性作用有限, 因为它对应用层是不透明的, 并且只覆盖单个连接的范围. HTTP 消息经常经过一连串彼此独立的连接. 在连接之间, 存在数据损坏的可能性. HTTP 完整性机制可以让端点, 或使用 HTTP 的应用, 检测数据损坏并决定如何处理. 一个示例用例是帮助跨系统边界进行故障检测和诊断.

本文档为 HTTP 定义两种摘要完整性机制. 第一种是内容完整性, 作用于所传送的内容 (Section 6.4 of [HTTP]). 第二种是表示数据完整性, 作用于表示数据 (Section 8.1 of [HTTP]). 这支持高级用例, 例如验证某个资源的完整性, 该资源由通过多个请求或连接检索到的部分重新构造而成.

本文档废止 [RFC3230], 因而也废止 Digest 和 Want-Digest HTTP 字段; 参见 Section 1.3.

1.1. 文档结构​

本文档结构如下:

  • 新的请求与响应头部字段和尾部字段定义.

    • Section 2 (Content-Digest),
    • Section 3 (Repr-Digest), 以及
    • Section 4 (Want-Content-Digest and Want-Repr-Digest).

  • 特定于表示数据完整性的考虑事项.

    • Section 3.1 (State-changing requests),
    • Section 3.2 (Content-Location),
    • Appendix A 包含消息交换中表示数据的完整示例, 以及
    • Appendixes B and C 包含消息交换中 Repr-Digest 和 Want-Repr-Digest 字段的完整示例.

  • Section 5 给出哈希算法考虑事项, 并定义未来条目的注册程序.

1.2. 概念概述​

本文档定义的 HTTP 字段可用于 HTTP 完整性. 发送方选择一个哈希算法, 并根据与 HTTP 消息相关的输入计算摘要. 算法标识符和摘要通过 HTTP 字段传输. 接收方可以出于完整性目的验证摘要. 哈希算法注册在 "Hash Algorithms for HTTP Digest Fields" 注册表中 (see Section 7.2).

摘要计算所依据的数据取决于 HTTP 消息的用例. 本文档为 HTTP 表示数据和 HTTP 内容提供了不同字段.

有些用例需要 HTTP 内容字节的简单摘要. Content-Digest 请求和响应头部字段及尾部字段被定义为支持内容摘要 (Section 6.4 of [HTTP]); 参见 Section 2.

对于更高级的用例, 定义了 Repr-Digest 请求和响应头部字段及尾部字段 (Section 3). 它包含一个摘要值, 该值通过将哈希算法应用于选定表示数据 (Section 8.1 of [HTTP]) 来计算. 让 Repr-Digest 基于选定表示, 可以直接把它应用到以下用例: 消息内容需要某种处理后才能被视为资源的表示, 或者内容传送的是资源的部分表示, 如范围请求 (see Section 14 of [HTTP]).

Content-Digest 和 Repr-Digest 支持哈希算法敏捷性.Want-Content-Digest 和 Want-Repr-Digest 字段分别允许端点表达对 Content-Digest 和 Repr-Digest 的兴趣, 并在二者中表达算法偏好.

Content-Digest 和 Repr-Digest 统称为 "完整性字段".Want-Content-Digest 和 Want-Repr-Digest 统称为 "完整性偏好字段".

完整性字段与 Content-Encoding 和 Content-Type 头部字段相关联. 因此, 在使用 HTTP 传输时, 给定资源可能具有多个不同的摘要值.

完整性字段适用于 HTTP 消息内容或 HTTP 表示. 它们不适用于 HTTP 消息或字段. 不过, 它们可以与保护元数据的其他机制结合使用, 如数字签名, 以便完整或部分保护 HTTP 交换的各个阶段. 例如, HTTP Message Signatures [SIGNATURES] 可用于签名完整性字段, 从而覆盖 HTTP 内容或表示数据.

本规范不定义认证, 授权或隐私机制.

1.3. 废止 RFC 3230​

[RFC3230] 为 HTTP 完整性定义了 Digest 和 Want-Digest HTTP 字段. 它还创造了 "instance" 和 "instance manipulation" 这些术语, 用来解释一些概念, 如选定表示数据 (Section 8.1 of [HTTP]), 而这些概念现在已经作为 HTTP 语义被更普遍地定义和实现.

经验表明, [RFC3230] 的实现对 "instance" 含义的解释并不一致, 导致互操作性问题. 最常见的问题与以下错误有关: 使用 (我们现在称为) 消息内容来计算摘要, 而不是按最初意图使用 (我们现在称为) 表示数据. 有趣的是, 时间也表明消息内容摘要可对某些用例有益, 因此很难判断不符合 [RFC3230] 是有意还是无意.

为解决 Digest 和 Want-Digest 各实现之间潜在的不一致和歧义, 本文档废止 [RFC3230]. 本文档定义的完整性字段 (Sections 2 and 3) 和完整性偏好字段 (Section 4) 与当前 HTTP 语义更好地对齐, 且名称更清楚地表达了预期用途.

1.4. 记号约定​

本文档中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 按 BCP 14 [RFC2119] [RFC8174] 中所述解释, 但仅当它们如这里所示以全大写形式出现时才如此解释.

本文档使用 [RFC5234] 定义并由 [RFC7405] 更新的扩展 BNF. 这包括规则 CR (carriage return), LF (line feed), 和 CRLF (CR LF).

本文档使用 [STRUCTURED-FIELDS] Section 3 中的以下术语来规定语法和解析: Boolean, Byte Sequence, Dictionary, Integer, 和 List.

本文档中的 "representation", "selected representation", "representation data", "representation metadata", "user agent", 和 "content" 定义按 [HTTP] 中所述解释.

本文档使用 [FOLDING] 中描述的行折叠策略.

哈希算法名称遵循其定义文档中使用的大小写 (例如 SHA-1, CRC32c).

HTTP 消息使用 Algorithm Key (algorithms) 指示哈希算法. 当本文档在正文中引用 Algorithm Key 时, 会加引号 (例如 "sha", "crc32c").

术语 "checksum" 描述将算法应用于字节序列后得到的输出, 而 "digest" 只用于指字段中包含的值.

"完整性字段" 是 Content-Digest 和 Repr-Digest 的统称.

"完整性偏好字段" 是 Want-Repr-Digest 和 Want-Content-Digest 的统称.

最后于 更新