Repr-Digest header
HTTP Repr-Digest 请求和响应头提供了目标资源所选表示形式的摘要。它可用于在接收和重构后验证整个所选表示形式的完整性。
所选表示形式是通过内容协商选择的资源特定格式。有关表示形式的详细信息可以从表示形式头中确定，例如Content-Language、Content-Type和Content-Encoding。
表示形式摘要适用于整个表示形式，而不是用于发送消息的编码或分块。 Content-Digest 适用于特定消息的内容，并会根据每条消息的Content-Encoding和Content-Range具有不同的值。
语法
Repr-Digest: <digest-algorithm>=<digest-value>
// Multiple digest algorithms
Repr-Digest: <digest-algorithm>=<digest-value>,…,<digest-algorithmN>=<digest-valueN>
指令
<digest-algorithm>-
用于创建表示形式摘要的算法。只有两个已注册的摘要算法被认为是安全的：
sha-512和sha-256。不安全（遗留）的已注册摘要算法有：md5、sha（SHA-1）、unixsum、unixcksum、adler（ADLER32）和crc32c。 <digest-value>-
使用
<digest-algorithm>表示形式的摘要字节。摘要算法的选择也决定了要使用的编码：sha-512和sha-256使用base64编码，而一些遗留摘要算法（如unixsum）使用十进制整数。与规范的早期草案相反，标准base64编码的摘要字节作为字典语法的一部分用冒号（:，ASCII 0x3A）封装。
不鼓励使用不安全的摘要算法，因为碰撞可以实际强制发生，从而使摘要的用处变弱。除非与遗留系统一起工作（这不太可能，因为大多数系统会期望已弃用的Digest头并且不理解此规范），否则请考虑省略Repr-Digest，而不是包含一个使用不安全摘要算法的摘要。
描述
以前的规范中定义了Digest头，但它被证明存在问题，因为摘要所适用的范围不明确。具体来说，很难区分摘要是应用于整个资源表示形式还是应用于HTTP消息的特定内容。因此，为了分别传达HTTP消息内容摘要和资源表示形式摘要，指定了两个独立的头（Content-Digest和Repr-Digest）。
示例
用户代理在请求中发送 Repr-Digest
在以下示例中，用户代理使用 SHA-512 发送消息内容的摘要。它同时发送Content-Digest和Repr-Digest，两者由于Content-Encoding而有所不同。
POST /bank_transfer HTTP/1.1
Host: example.com
Content-Encoding: zstd
Content-Digest: sha-512=:ABC…=:
Repr-Digest: sha-512=:DEF…=:
{
"recipient": "Alex",
"amount": 900000000
}
服务器可以计算其已接收内容的摘要，并将结果与Content-Digest或Repr-Digest头进行比较，以验证消息完整性。在像上面示例中的请求中，Repr-Digest对服务器更有用，因为它是在解码后的表示上计算的，并且在不同场景下会更一致。
Repr-Digest 和 Content-Digest 相同的 HTTP 响应
HTTP 服务器可以在一条消息中发送未编码的完整表示。在这种情况下，对于相同的摘要算法，Repr-Digest和Content-Digest具有相同的值。
…
Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:
Content-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:
…
Content-Type: text/yaml
Content-Encoding: br
Content-Length: 38054
Content-Range: 0-38053/38054
…
[message body]
Repr-Digest 和 Content-Digest 不同的 HTTP 响应
服务器可能会压缩内容以进行发送。在这种情况下，Content-Digest将取决于Content-Encoding，因此在响应中将与Repr-Digest头具有不同的值。
…
Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:
Content-Digest: sha-256=:293wcr5IoFAsDCzdoDXR1Qppgf2yxOPO1bvQ3nZQtuI=:, unixsum=54809
…
Content-Type: text/html; charset=utf-8
Content-Encoding: br
…
[message body]
在另一个响应中，服务器使用不同的压缩方法，导致新的Content-Digest，但Repr-Digest摘要相同。
…
Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:
Content-Digest: sha-256=:rv9Jivc4TmcacLUshzN3OdX7Hz+ORnQRaiTaIKZQ0zk=:
…
Content-Type: text/html; charset=utf-8
Content-Encoding: zstd
…
[message body]
使用 Want-Repr-Digest、Repr-Digest 和 Content-Digest 的成功 HTTP 请求-响应
以下PUT请求包含一个Want-Repr-Digest头，表示如果操作成功，服务器应包含一个带有sha-256摘要的Repr-Digest头。
PUT /api/transact HTTP/1.1
Want-Repr-Digest: sha-256=8
Content-Type: text/json
…
[message body]
服务器以成功的201 Created响应，其中包含Repr-Digest和Content-Digest头，分别带有表示形式和内容的sha-256摘要。
HTTP/1.1 201 Created
Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:
Content-Encoding: br
Content-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:
…
[message body]
使用 Repr-Digest 的不成功 HTTP 请求-响应
在以下消息中，用户代理请求具有特定 sha-256 摘要的资源。
GET /api/last-transaction HTTP/1.1
Accept: text/json
Repr-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:
…
服务器返回406 Not Acceptable，表示在给定资源的特定摘要的情况下操作失败。Repr-Digest头包含 SHA-256 摘要值，如果用户代理使用该值重复请求，则会得到成功的响应。
HTTP/1.1 406 Not Acceptable
Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:
…
规范
| 规范 |
|---|
| 摘要字段 |
浏览器兼容性
此头没有规范定义的浏览器集成（“浏览器兼容性”不适用）。开发人员可以使用fetch()设置和获取HTTP头，以提供特定于应用程序的实现行为。
另见
Content-Digest、Want-Content-Digest、Want-Repr-DigestETagContent-Encoding- API 数字签名 SDK 指南使用
Content-Digest进行 HTTP 调用中的数字签名 (developer.ebay.com)