为什么我们需要多部分数据格式的边界？

Question

标题说明了一切。我的意思是假设我们正在尝试上传多个图像，对于每个多部分部分，我们将有子标题，例如

Content-Disposition: form-data; name="file"; filename="mia.jpeg"

Content-Type: image/jpeg

Content-Length: 5379

Content-Length 足以告诉解析器此内容部分何时结束并开始另一部分。但我很可能遗漏了一些东西，你能帮忙吗？

Answer 1

Content-Length不是多部分内容的要求。旧 RFC部分解决了使用长度的问题：5.2 其他数据编码而不是多部分许多人建议使用新的 mime 顶级类型“聚合”，例如聚合/混合或“数据包”的内容传输编码来表达不确定长度的二进制数据，而不是依赖于多部分样式的边界。虽然这很有用，但“多部分”机制已经很好地建立起来，在发送客户端和接收服务器上都易于实现，并且与处理二进制数据的多种组合的其他方法一样有效。但是，该文本不在当前文本中；length根本没有出现在里面。如果您将发送流的结果视为多部分帖子的一部分，而它可能事先不知道该流数据的长度，则这尤其有意义。如果需要长度，则需要缓存或读取两次。

Answer 2

为什么我们需要多部分数据格式的边界？边界是用于允许服务器将消息拆分为块或正文部分的分隔符。多部分请求可以包含任意数量的正文部分。这些multipart/form-data请求目前在RFC 7578 中定义。每个部分由它自己的内容头（零个或多Content-个头字段）和一个正文组成。值得一提的是，边界定界符不得出现在任何封装部分内。另一个相关文档是RFC 2046，它定义了多部分 MIME 数据流：正文必须包含一个或多个正文部分，每个部分前面有一个边界分隔线，最后一个部分后面跟一个结束边界分隔线。在其边界定界符之后，每个正文部分由一个标题区、一个空行和一个正文区组成。