20

HTTP 协议长期以来一直支持多部分响应。我以前曾将它们用于配备适当消费者的 API，但浏览器对它们的支持似乎不是很好，在过去五年中也没有改进。我很难找到很多关于为什么会这样的信息。我希望能够通过发送我知道的 web 应用程序在初始请求时需要的所有资产来减少 HTTP 请求，特别是对于使用像 Backbone.js 这样的客户端框架的应用程序。

是否有任何白皮书、交易文章、失败的实验或其他证据说明为什么浏览器制造商或 Web 性能传播者都没有关注这个长期存在的 HTTP 结构？

完全清楚，我不是在寻找意见，而是在寻找真正的证据来表明为什么会这样。例如，如果 Mozilla 几年前发布了一些关于此的内容，或者 Firefox 错误跟踪器中有一张已关闭的票证，其中主要开发人员评论了他们为什么不实施此功能。

4

2 回答 2

4

实际上，旧版本的 IE 将处理多部分应用程序/八位字节流响应并在下载操作期间保存所有文件，但这最近已被删除（我认为从 IE7 开始）并且仅适用于下载。

我怀疑您是否会找到您正在寻找的“证据”，因为我认为您提出的建议与 HTTP 规范的“精神”不符。我将尝试解释我的意思。HTTP 的基本范式是客户端驱动的请求和服务器对该请求的响应。但是您似乎建议服务器将返回任意文件，并假设客户端知道如何处理它们。

但是，如果您建议客户端首先明确请求多个文件，那么我会说您可能会做一些事情。HTTP 1.1 规范确实允许 Accept client-request 标头指示多部分支持，因此这似乎是 HTTP 设计者设想的这种工作方式。不幸的是，规范对客户端应该如何识别它期望接收的文件保持沉默，如果你在真空中查看 HTTP，这是可以理解的，正如它所定义的那样，而不是通过浏览器和网站的镜头。这是一个由客户端和服务器来解决的实现细节。这是一个适用于不同层的问题——内容是什么以及如何使用它，而不是如何请求和传输它。

当然，很容易想象各种解决方案，但是如果没有可参考的标准，浏览器开发人员的努力似乎就不值得了。我可以想象像微软这样的人（控制着广泛采用的服务器和浏览器）实现这一点，但他们会发明一个规范，人们会抱怨。显然我们已经决定最好等 10 年让 W3C 就某事达成一致……

于 2012-05-24T03:57:08.160 回答
2

直接来自 W3 组织本身（在http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2）：

3.7.2 多部分类型

MIME 提供了许多“多部分”类型——将一个或多个实体封装在单个消息体中。如 RFC 2046 的第 5.1.1 节中所定义，所有多部分类型共享一个通用语法

[40]，并且必须包含边界参数作为媒体类型值的一部分。消息体本身就是一个协议元素，因此必须只使用 CRLF 来表示正文部分之间的换行符。与 RFC 2046 不同，任何多部分消息的结尾必须为空；HTTP 应用程序不得传输结语（即使原始多部分包含结语）。存在这些限制是为了保持多部分消息体的自定界性质，其中消息体的“结束”由结束的多部分边界指示。

一般来说，HTTP 对待多部分消息体与任何其他媒体类型没有区别：严格地视为有效负载。一个例外是“multipart/byteranges”类型（附录 19.2），当它出现在 206（部分内容）响应中时，它会被 13.5.4 和 14.16 节中描述的一些 HTTP 缓存机制解释。在所有其他情况下，HTTP 用户代理应该遵循与 MIME 用户代理在收到多部分类型时相同或相似的行为。多部分消息正文的每个正文部分中的 MIME 标头字段对 HTTP 没有任何意义，超出其 MIME 语义定义的意义。

一般来说，HTTP 用户代理应该遵循与 MIME 用户代理在收到多部分类型时相同或相似的行为。如果应用程序接收到无法识别的多部分子类型，应用程序必须将其视为等同于“multipart/mixed”。

  Note: The "multipart/form-data" type has been specifically defined
  for carrying form data suitable for processing via the POST
  request method, as described in RFC 1867 [15].
于 2013-06-01T19:17:59.470 回答