Content-Range 用于恢复未知长度的文件答案

【问题标题】：Content-Range for resuming a file of unknown lengthContent-Range 用于恢复未知长度的文件
【发布时间】：2013-03-05 22:52:23
【问题描述】：

我从已经压缩的现有材料（使用 Node）即时创建了一个长度未知的 ZIP 存档。在 ZIP 存档中，文件只是被存储； ZIP 仅用于拥有一个容器。这就是缓存创建的 ZIP 文件没有意义的原因 - 不涉及真正的计算。

到目前为止，好的。现在我想允许恢复下载，我正在阅读有关 Accept-Range、Range 和 Content-Range HTTP 标头的信息。下载失败的客户端会要求一个开放范围，例如：Range: bytes=8000000-。

我该如何回答？根据RFC 2616 § 14.16，我的答案必须包含一个 Content-Range 标题：

与 byte-ranges-specifier 值（参见第 14.35.1 节）不同，byte-range-resp-spec 必须只指定一个范围，并且必须包含范围的第一个和最后一个字节的绝对字节位置。

所以我不能只发送“从位置 X 开始的所有内容”，我还必须指定发送的最后一个字节 - 要么只发送已知大小的一部分，要么提前计算长度。这两种想法都不适合我的情况。还有没有其他可能？

【问题讨论】：

【解决方案1】：

回答自己：看起来我必须在 (1) 对长度未知的文件进行分块编码，或 (2) 知道其 Content-Length（或至少当前部分的大小）之间做出选择，允许恢复下载（以及进度条）。

我可以忍受 - 对于我的每个 ZIP 文件，长度都是相同的，因此我可以将其存储在某个地方并重新用于后续下载。我很惊讶 HTTP 协议不允许恢复未知长度的下载。

【讨论】：

【解决方案2】：

响应内容类型为“multipart/byteranges”，包括每个部分的 Content-Range 字段。

推理：

回复带有“Range”标头的请求时，成功的部分响应应报告 206 HTTP 状态代码 (14.35.1 Byte Ranges section)
206 响应建议“Content-Range”标头或“multipart/byteranges”Content-Type (10.2.7 206 Partial Content)
“Content-Range”标头不能添加到响应中，因为它不允许省略结束位置，所以唯一的方法是使用“multipart/byteranges”Content-Type

【讨论】：