摘要

  • HTTP 206 证明服务器成功交付了所选表示中的一个或多个声明区间；它本身不证明分批取得的区间能组成一个完整对象。
  • 断点续传和缓存拼接必须共享同一个强验证器，核对精确区间覆盖，并在结束时验证完整表示。
  • 206 响应中的 Content-Length 通常是本次消息正文的长度，Content-Range 才说明字节位置以及所选表示的完整长度。
  • 应保存“范围拼接收据”，记录版本身份和每个已接受区间，而不能把进度条达到百分之百当作充分证据。

设想从对象存储下载一份路由数据归档。连接在中途断开，客户端下载缺失部分之前，源站把文件替换成大小相近的新快照。两次请求都返回 206，所有请求区间都成功到达，字节计数也达到预期总量。然而，最终文件的前半段来自旧版本，后半段来自新版本，因为续传请求没有被同一个强验证器约束。

这是一个假设场景，并非对任何存储服务商的事故指控。HTTP 已经提供避免该问题的机制。真正的操作失误，是让一个局部响应状态承担它没有表达的整体证明。

成功的范围响应只证明有限事实

RFC 9110 将 206 Partial Content 定义为：服务器通过传输所选表示的一个或多个部分，成功满足范围请求。这个状态准确说明声明区间已经交付，却没有声明客户端已经拥有完整表示。

接收方必须检查 Content-Type 与每个 Content-Range，判断响应究竟包含哪些部分、是否还需继续请求。单一区间的 Content-Range 给出首尾位置，通常还给出所选表示的完整长度；Content-Length 则通常只计算当前 206 消息正文的字节。混淆两者，会把正确的局部响应误当成完成证明。

多区间响应还增加了记账义务。返回顺序可以不同于请求顺序，服务器也可能合并区间或忽略无法满足的区间。因此，覆盖率必须依据实际返回的区间计算，不能依据请求顺序、响应数量或进度条推断。

连续性属于表示，而不是 URL

URL 不变不代表字节不变。内容协商、部署、生成时刻或源站更新，都可能在目标 URI 不变时改变所选表示。安全续传必须证明旧片段与新片段属于同一版本。

If-Range 正是为这条边界设计的。客户端可以带着验证器请求剩余区间；若验证器仍匹配，服务器返回相应部分；若不再匹配，服务器忽略 Range，改为返回完整的新表示。RFC 9110 禁止在 If-Range 中使用弱 ETag，因为逐字节拼接需要能区分不同表示的强验证器。

所以，If-Range 请求后出现 200 并不是应当绕过的“低效率失败”，而是旧片段不能再安全延伸的证据。客户端应丢弃原有拼接状态，以新返回的完整表示重新开始。

缓存承担同样的义务

RFC 9111 允许缓存通过后续范围请求补全未完成响应，但只有在所有区间共享同一个强验证器且符合局部内容组合规则时，才允许合并。

因此，缓存命中率和已存字节量都不够。操作人员还需知道缓存键及内容协商上下文、每个区间的强验证器、最新响应如何更新头字段，以及最终对象是新鲜的、已经重新验证的，还是被明确允许以过期状态提供。下载器、镜像和对象存储网关只要持久保存片段，就面对同样的问题，即使产品没有称自己为缓存。

在正确层次验证完整性

RFC 9530 区分两种范围：Content-Digest 针对一条 HTTP 消息的内容计算，Repr-Digest 针对完整的所选表示数据计算。对于 206，前者可以核验本次片段，后者可以核验跨多次请求或连接重建出的完整对象。

摘要不能替代验证器。验证器证明各片段属于同一版本，Repr-Digest 检查拼接后的最终字节，区间表则证明没有被总数掩盖的空洞或重叠。完整性字段也不定义认证、授权或隐私。R063 处理的是更窄的问题：取回的字节是否确实形成一个一致表示。

建立范围拼接收据

接受第一个局部响应时就开启收据，记录目标 URI、方法、影响表示选择的请求头、内容编码、媒体类型、完整长度、强验证器、观察时间，以及响应来自源站、中间节点还是本地存储。

每接受一个部分，都记录实际返回区间、响应状态、验证器、来源、缓存状态，以及可用时的片段摘要。把区间归一化，避免重叠片段虚增进度，并让缺口始终可见。一旦某片段的验证器或表示元数据与冻结身份冲突，就拒绝合并。

只有在区间精确覆盖整个表示，且重建字节通过预期 Repr-Digest 或独立取得的表示哈希后，收据才能关闭。如果强验证器改变、缺失或含义不清，就应放弃混合拼接并重新下载完整当前表示。这会增加流量，却保护了更重要的事实：被处理的对象确实以一个完整版本存在过。

来源