题干与适用场景
一个文件上传 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、签名覆盖和业务幂等状态。
代理应该删除上游摘要吗？
只有当代理改变了摘要覆盖的字节且无法重算时才应删除或标记不可用；可重算时应基于最终消息或表示生成新的字段，并记录边界责任。