我想生成一个多部分字节范围响应。有没有办法在不扫描我要发送的每个段的情况下执行此操作，因为我需要生成多部分边界字符串？
例如，我可以让用户请求一个字节范围，让我获取并扫描2GB数据，在我的情况下，我将这些数据作为字符串等加载到我的（慢）VM中。理想情况下，我想简单地在响应中声明一个部分具有一定长度的字节数，并完成它。是否有任何工具可以为我提供此选项？我看到许多开发人员只是将UUID作为边界使用，并且可能愿意冒一个很小的概率，它会出现在部件的某个地方，但这种风险似乎足够小，多人正在接受它？
为了更详细地解释：在我的情况下提前扫描部件（在生成响应之前）并不可行，因为我需要通过HTTP从上游服务获取它们。这意味着我实际上必须首先预取整个部分以计算不匹配的多部分边界，然后才能将该部分拼接到响应中。
答案 0 :(得分：1)
假设数据可以是任意的，我不知道如何在不扫描数据的情况下保证没有碰撞。
如果数据的格式非常有限（比如... base 64编码？），你可以选择一个已知为该格式的非法字节序列的边界。
即使您的边界 与数据冲突，也必须跟着Content-Range之类的标题，这更不可能，因此客户可能会将其视为错误而不是消耗错误的数据。
主要的Web服务器使用非常简单的策略。 Apache grabs 8 random bytes在启动时以十六进制呈现它们。 nginx使用a sequential counter左边填充零。
UUID旨在避免与其他UUID 发生冲突，而不是与任意数据冲突。 UUID不太可能是一个好的边界而不是相同长度的完全随机的字符串。此外，一些UUID变体包括您可能不想透露的信息，例如您机器的MAC地址。
理想情况下，我想简单地在响应中声明一个部分具有一定数量字节的长度，并完成它。是否有任何工具可以为我提供此选项？
也许您可以避免支持多个范围，只需告诉客户分别请求每个范围。在这种情况下，您不使用多部分格式，因此没有问题。
如果您确实想在一个响应中发送多个范围，则RFC 7233需要多部分格式，这需要边界字符串。
当然，您可以发明自己的机制而不是RFC 7233.在这种情况下：
multipart/byteranges媒体类型。您必须提出自己的媒体类型。Range请求标头。chunked transfer coding可能很有用，但您不能单独依赖它，因为它是连接的属性，而不是有效负载的属性。