9

我从已经压缩的现有材料（使用 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 开始的所有内容”，我还必须指定发送的最后一个字节——要么只发送已知大小的一部分，要么提前计算长度。这两种想法都不适合我的情况。还有其他可能吗？

4

2 回答 2

1

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

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

于 2013-03-18T21:38:36.260 回答
0

响应“multipart/byteranges”内容类型，包括每个部分的内容范围字段。

推理：

  1. 回复带有“Range”标头的请求时，成功的部分响应应报告 206 HTTP 状态代码（14.35.1 字节范围部分）

  2. 206 响应建议“内容范围”标头或“多部分/字节范围”内容类型（10.2.7 206 部分内容）

  3. “Content-Range”标头不能添加到响应中，因为它不允许省略结束位置，所以唯一的方法是使用“multipart/byteranges”Content-Type

于 2014-07-09T17:13:56.737 回答