題干與適用場景
一個檔案上傳 API 需要讓客戶端確認收到的 HTTP 內容未被閘道或快取改寫。請依 RFC 9530 設計 Content-Digest、Repr-Digest 與 Want-Repr-Digest 的使用方式，並說明它們與 TLS、簽章和重試的邊界。
題目考察候選人能否把摘要綁定到正確的 HTTP 層次：Content-Digest 針對實際訊息內容，Repr-Digest 針對選定表示，Want-Repr-Digest 表達接收方對表示摘要的偏好。摘要可驗證內容完整性，但單獨不能證明誰送出了訊息。
面試官考察點
重點包括：區分訊息內容和表示、選擇安全演算法、處理請求與回應協商、代理與壓縮邊界、串流計算、摘要失敗狀態機，以及把摘要與認證簽章、TLS、重試冪等正確組合。
30 秒回答框架
「我先定義校驗物件和位元組邊界。上傳請求由客戶端計算 Content-Digest，伺服器讀取實際訊息位元組時串流校驗；回應可由伺服器傳送 Repr-Digest，客戶端依最終表示校驗。客戶端用 Want-Repr-Digest 宣告偏好的演算法，伺服器只選擇允許的強演算法並記錄協商結果。摘要失敗立即終止交付或落庫，認證仍由 TLS、HTTP Message Signatures 或存取權杖負責。」
分步驟深入解答
第一步：定義要保護的物件
先寫清楚是傳輸中的訊息內容，還是經內容協商後的表示。Content-Digest 對應實際傳輸訊息內容；Repr-Digest 描述目標資源的選定表示。不能用一個表示摘要去驗證經轉碼的另一份位元組。
第二步：選擇摘要演算法
協定白名單只保留 SHA-256 或 SHA-512 等目前允許的演算法，拒絕 MD5、SHA-1 等遺留演算法。解析結構化欄位時檢查重複演算法、未知參數和異常編碼，避免不同函式庫對同一值產生不同解讀。
第三步：設計請求校驗
上傳客戶端在傳送前依最終訊息位元組計算 Content-Digest。伺服器邊讀邊計算，直到訊息結束後再比較摘要；比較失敗時不提交物件、不發布事件，也不把部分結果視為成功。大檔案不應為校驗而完整快取在記憶體。
第四步：設計回應校驗
伺服器可以在回應中傳送 Repr-Digest，客戶端對解碼後得到的選定表示依協商規則計算並比較。若回應經過壓縮，協定必須明確摘要針對壓縮前的表示還是線上訊息內容，客戶端不能混淆兩種層次。
第五步：使用 Want-Repr-Digest
客戶端可在請求中傳送 Want-Repr-Digest，列出演算法偏好和權重。伺服器可以滿足、選擇另一項允許演算法或省略該回應欄位；客戶端應區分「未提供摘要」和「摘要不匹配」，不能把缺失當成驗證通過。
第六步：處理代理與快取
快取命中時仍要回傳與目前表示對應的摘要。若閘道重新壓縮、轉碼或拼接內容，它必須重新計算相關摘要；只複製上游欄位會造成錯誤校驗。代理改寫未被摘要覆蓋的訊息欄位不會自動破壞摘要，但會影響更高層的簽章或授權語義。
第七步：組合認證與防重播
摘要只證明位元組對應關係，不能證明送出方身分，也不能阻止合法訊息再次送出。需要送出方認證時，用 TLS、HTTP Message Signatures 或權杖；需要避免重複扣款時，使用 nonce、時間視窗和業務冪等鍵。不要把摘要值當成授權憑證。
第八步：定義失敗與觀測
摘要不匹配、演算法不允許、欄位格式錯誤和欄位缺失應有不同指標與錯誤碼。上傳介面在校驗失敗後清理暫存物件，回應校驗失敗則丟棄快取結果並觸發重試策略。日誌記錄演算法、請求 ID、大小和失敗類別，不記錄敏感內容或完整載荷。
設計取捨與邊界
Content-Digest 還是 Repr-Digest
Content-Digest 更適合校驗這一次 HTTP 訊息實際傳輸了什麼；Repr-Digest 更適合快取、內容協商和資源表示驗證。兩者可同時出現，但必須在協定文件中寫出位元組邊界和解碼順序。
摘要還是數位簽章
摘要計算成本低，適合偵測傳輸或儲存內容變化；數位簽章還可提供持鑰方認證和跨系統驗證。簽章輸入可以包含摘要欄位，使內容完整性與請求方法、目標資源綁定，但摘要本身沒有身分屬性。
嚴格失敗還是降級交付
支付、軟體套件和合規歸檔等場景應在摘要缺失或不匹配時拒絕交付。可選摘要的普通靜態資源可以記錄告警後繼續，但必須讓呼叫方知道目前回應未完成完整性驗證，不能靜默標記為可信。
失敗演練與演進計畫
閘道重新壓縮回應
讓閘道改變壓縮方式，驗證客戶端仍依協定指定的表示層次計算摘要；若摘要針對被改寫的層次，閘道必須重新產生欄位。
上傳途中竄改位元組
在代理中替換一個位元組，確認伺服器在提交物件前報告 Content-Digest 不匹配，並清理暫存檔與後續事件。
演算法降級與欄位缺失
送出包含遺留演算法的偏好，驗證伺服器拒絕不允許的選擇；再移除 Repr-Digest，確認客戶端進入「未驗證」分支，而不是成功分支。
常見誤區與追問
誤區一：把摘要當作身分認證
追問：攻擊者能否重新計算摘要並送出自己的內容？可以，因此還需要 TLS、簽章或權杖確認送出方。
誤區二：忽略壓縮和表示層次
追問：上游摘要能否直接複製到重新壓縮後的回應？只有摘要覆蓋的位元組層次未改變時才可以，否則必須重算。
誤區三：把欄位缺失當成校驗通過
追問：客戶端要求摘要但伺服器未回傳時怎麼辦？依策略標記未驗證或拒絕，不應將缺失解釋為匹配。
延伸追問與參考答案
為什麼上傳請求也能使用 Content-Digest？
請求送出方可以在傳輸前或串流結束時提供訊息內容摘要，接收方據此驗證落庫前的實際位元組；大檔案應串流計算而非整段快取。
摘要欄位適合防止重播嗎？
不適合。相同的合法訊息可以被再次送出，防重播要依靠時間視窗、nonce、簽章覆蓋和業務冪等狀態。
代理應該刪除上游摘要嗎？
只有當代理改變了摘要覆蓋的位元組且無法重算時才應刪除或標記不可用；可重算時應依最終訊息或表示產生新的欄位，並記錄邊界責任。