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)