摘要

  • draft-ietf-httpbis-resumable-upload-12 中的 Upload-Offset 是临时上传资源对已处理表示数据前缀的应用层确认，并保证客户端无需重传这段前缀。
  • 偏移量不证明显式完成、摘要匹配、整件扫描通过、权限仍有效、目标资源已提交或下游业务已经发生；每跨过一道边界，都必须有新的可归责回执。

客户端问服务器：“我还要从哪里继续？”服务器回答：“从第八百万个字节开始。”客户端据此释放了前面的缓冲区。这个决定完全合理，因为服务器承诺前缀不必重传。

另一个系统却把同一个数字写成“对象已入库”，触发发布审批、删除源文件，并向用户发出成功通知。它没有多拿到一份证据，只是给原证据换了一个更宽的名字。

2026 年 7 月 6 日发布的 Resumable Uploads for HTTP 第 12 版，正好揭示这种扩权。它是 IETF HTTP 工作组的活跃 Internet-Draft，拟进入 Standards Track，有效期至 2027 年 1 月 7 日；它不是 RFC、部署统计、互操作结论或采用率证明。草案解决的是中断后如何延续上传，不是如何让一个计数器替所有应用判断负责。

临时资源保存连续性，目标资源决定意义

初始请求指向真正承载应用语义的资源：创建记录、替换文件、提交材料，或者启动某项处理。为了支持恢复，服务器另建一个只对应一份表示数据的临时上传资源。客户端可以查询它的进度、追加数据或取消。

这两个资源不是同一个角色。临时资源像连续性账本，回答哪些字节已经进入可继续的状态。原始目标资源才解释方法、请求字段和完整表示数据，并决定接受、拒绝或提前终止。

因此，有上传资源 URI，不代表目标对象已经存在；能够继续 PATCH，也不代表主体仍有权完成原始动作。网络中断前后，传输事实可能保持不变，配额、角色、案件状态和内容政策却可能已经变化。

完成后，服务器可以立即删除临时资源，也可以保留一段时间，让没收到最后响应的客户端查询结果。于是，后来看到 URI 不存在，也不能脱离保留策略直接断言成功或失败。最终结论必须来自目标资源的响应与应用记录。

Offset 高于传输 ACK，又低于对象承诺

草案把 offset 定义为上传资源已经处理的表示数据字节数。这里强调的是应用层处理。底层 TCP、QUIC 或 HTTP 传输可能已经收包并确认，数据仍可能停留在缓冲区，还没有进入上传状态。

服务器返回 Upload-Offset 时，给出一项有力但有限的保证：该前缀已处理，不需要重新发送。客户端可以释放为重试保留的内存、磁盘分片或生产缓存。这是协议节省时间与带宽的核心价值。

它没有保证对象已经放入最终存储、跨区复制、通过病毒扫描、匹配摘要、获得业务批准或对外可见。把 processed 翻译成 accepted，不是简化术语，而是把账本权限扩大成裁决权。

已处理数据不能从上传资源中倒退删除，所以 offset 必须单调不减。如果服务器丢失了任何必要状态，草案要求停用这个上传资源并拒绝后续交互。系统不能为了维持“可用”外观，猜一个较小值继续，也不能凭缓存重建一个看似合理的较大值。证据断裂时，诚实失败比伪造连续性更可靠。

两个数字相等，仍然可能没有结束

length 描述表示数据的总长度，可能在创建时已知，也可能到流结束才确定。offset 描述已经处理的前缀。两者相等很容易被写成完成条件，但草案明确指出：offset 可以等于 length，而上传仍是不完整状态。

原因在于完成必须被显式表达。流式生产者可能暂时没有更多字节，却还没有关闭；分段策略可能已经发送所有内容，随后再用一个空请求声明结束。算术相等不能代替状态转换。

Upload-Complete 因而是独立布尔量。在创建或追加响应中，真值意味着接下来按最初目标资源的语义理解响应；假值仍属于可恢复上传过程。这里还有一个容易误读的例外：目标资源可以提前响应，所以 Upload-Complete: ?1 并不必然表示完整表示数据都已传过网络。

运营界面应当把“已知长度全部处理”和“上传显式完成”显示为两个状态。只有目标资源的最终回执才能继续回答“业务动作是否成功”。

104 是找得到回程，不是抵达终点

104 Upload Resumption Supported 是临时响应。服务器可以早早告诉客户端临时资源的 URI 与限制，也可以在处理过程中用后续 104 回报 offset。客户端一旦拿到 URI，即便连接后来中断，也有机会查询和续传。

临时响应不是原始请求的最终结果。若前端收到 104 就亮绿灯，它把“服务器提供恢复入口”误报为“目标已经接受”。在乐观创建策略中，客户端直接发送整份表示数据，并期待及时收到 104。如果中断发生得太早，或者中间设备丢弃临时响应，服务器可能已有部分数据，客户端却不知道到哪里恢复。

谨慎策略先发送空的创建请求，取得 URI 和限制，再开始传大体积内容。多一次往返换来明确恢复坐标。选择哪种方式取决于重传成本和中间设备能力，但两种方式都没有改变目标资源的最终权限。

409 把分歧暴露出来

每次追加都携带客户端认定的当前 offset。若与服务器不一致，服务器返回 409 Conflict，同时给出自己的 offset 和完成状态。它阻止迟到的重试、两个进程或丢失响应后的旧记忆，把内容悄悄接在错误位置。

正确做法不是自动把本地数字加到服务器数字上，也不是强制覆盖远端状态，而是重新查询、确认源表示数据身份、比较分歧前缀，再按明确策略继续。服务器多出的字节可能已经在响应丢失前处理；客户端重发会造成重复。客户端多出的字节也可能只到达了传输层，从未被应用处理。

同一个上传资源不支持并行传输，服务器应串行处理追加与取消。这能缩小竞态，却不能让没收到最终响应的客户端凭空知道结果。状态查询与目标动作的幂等设计仍然必要。

完整性与安全检查必须看见组装后的整体

进度正确，不代表内容正确。内容摘要和表示摘要有各自覆盖范围与验证时点。系统必须记录是否要求摘要、验证了哪组字节、结果是什么。offset 既不包含摘要，也不证明摘要被检查。

分段还会改变安全控制的视野。若扫描器把每个 PATCH 当成独立文件，一段危险模式可以跨越两个请求边界，从每次局部扫描中消失。只有组装后的完整表示经过检查，才有资格进入执行、解析或发布阶段。

元数据同样是不可信输入。文件名、媒体类型、处置字段或存储提示不会因为字节计数准确就自动安全。可恢复上传解决了连续性问题，也要求原本依赖“单个完整请求”的安全控制重新选择执行位置。

URI 难猜，不等于权限永久有效

上传资源 URI 是修改临时状态的标识符。服务器应只允许获授权客户端访问，并让 URI 难以猜测；若其中携带路由或存储信息，还要避免暴露内部结构。

但链接保密只是降低发现风险，不是授权模型。一个上传可能持续数小时甚至更久。创建时有权限的人，最终提交时可能已经离职、角色被撤销、配额耗尽或审批失效。草案明确要求面对这种检查与使用之间的时间差，在最终化之前重新验证权限和配额。

于是，一条完整证据链至少有八级：传输层收到字节；上传资源处理前缀；客户端与服务器对 offset 和 length 对账；显式完成；完整性和内容政策通过；当前授权有效；目标资源提交；下游发布或业务效果发生。下一级永远不能从上一级自动推导。

来源与限制

冻结来源包括第 12 版及 Datatracker 历史、HTTP 工作组问题页面，以及 HTTP 语义、缓存、HTTP/1.1、HTTP/2、QUIC、Digest Fields、PATCH、Problem Details 和 Content-Disposition 的正式文档。它们证明机制与边界，不证明实际部署比例、性能、漏洞事件、互操作结果或任何厂商行为。

来源