Summary

  • Byte Range PATCH 草案第 05 版指出：服务器若不支持部分 PUT，可以忽略 Content-Range，把收到的片段当成完整资源替换原文件。
  • message/byterange 把单段写入的位置放进 PATCH 文档。没有已知范围的补丁，服务器必须以 400 或 422 拒绝。
  • 每段声明的 Content-Length 必须与范围长度一致；允许稀疏写入的服务器不得泄露未初始化内容。

草案的示例只有十二个字节，却足以把问题说透。文件原本是 0123456789 加一段换行。客户端想用 wxyz 覆盖第 2 到第 5 位，结果应当是 01wxyz6789 加原来的换行。若服务器按完整替换处理，最后只剩 wxyz。操作看起来成功了，文件却缩成了补丁本身。一个表示位置的字段，没有获得接收端的执行承诺。

第 2 节指出了具体陷阱：PUT 请求带 Content-Range，必须由服务器专门支持才会按范围工作。没有这项能力，服务器可以忽略该字段，照 PUT 的通常含义把请求体作为整个新资源。客户端的意图非常清楚，服务器的行为也符合它自己的语义；两者之间缺了共同接受的部分写入契约。

草案把这项契约移到 PATCH 的文档类型中。message/byterange 对应单段连续范围；multipart/byteranges 可带多段；拟议的 application/byteranges 提供二进制表示。示例把 Content-Range: bytes 2-5/12 写在补丁文档内，再放 wxyz。接收端若接受这种媒体类型，就必须按它的范围语义处理；不认识该格式，应在改动文件前拒绝。拒绝是可见的能力边界，安静地替换则是事后才看见的损失。

位置不是装饰字段

草案要求每个部分指明一段连续范围。服务器不知道写入位置，就必须返回 400 或 422。若部分内声明了 Content-Length，长度必须与范围完全吻合。四字节的目标不能悄悄塞入五字节内容。对于结束位置尚不确定的流，Content-Offset 可以指定起点；总长度不确定时，Content-Range 也可使用 *。不确定的是终点，起点仍得交代清楚。

文件末端另有一道危险线。紧挨末端写入，是扩展文件；越过末端写入，则留下没有定义内容的空洞。草案建议拒绝后一种请求。服务器如果允许稀疏文件，必须阻止未初始化数据外泄，并应当用零填充空洞。光看 HTTP 成功码，分辨不出追加和挖洞；必须读回结果。

第 4 节提出 Prefer: transaction=atomic 与 transaction=persist，分别表达“成功后再提交”和“中断时保留已接收部分”的偏好。服务器应通过 Preference-Applied 说明采纳了哪种偏好。这管的是传输中断后保留什么。更早的决定是：四个字节究竟放进原文件，还是成为新文件。把两件事混作“支持续传”，会让覆盖事故躲进漂亮的功能说明。

RFC 5789的 Accept-Patch 可以公告服务器理解哪些补丁文档类型。尚缺的是一组混合服务器实测：同样的范围 PUT 与 message/byterange PATCH，分别记录改动前后的字节、状态码和 ETag。这组证据会说明部署中的接收端实际把边界画在哪里。

草案及版本状态 · RFC 5789 · RFC 9110