Question

HTTP协议长期支持多部分响应。我以前曾经使用它们用于具有适当装备的消费者的API，但是它们似乎没有对它们的浏览器支持非常好，在过去的五年中也没有改进。我很难找到有关原因的信息。我希望能够通过发送我知道webapp在初始请求中需要的所有资产来减少HTTP请求，特别是对于使用Backbone.js等客户端框架的应用程序。

是否有任何白皮书，贸易文章，失败的实验或其他证据表明为什么浏览器制造商或网络性能福音传播者都没有为这个长期的HTTP构建支付费用？

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

Answer 1

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

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

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

当然，很容易想象各种解决方案，但如果没有标准可供参考，那么浏览器开发人员似乎无法保证这一点。我可以想象有人像微软（控制广泛采用的服务器和浏览器）实现这一点，但他们正在发明一个规范，人们会抱怨。显然我们已经决定等待10年才能让W3C达成一致意见......

Answer 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应用程序绝不能传输结尾（即使是   原始的multipart包含一个结尾）。这些限制存在于   为了保持多部分信息的自我划分性质 -   body，其中消息体的“end”由结尾指示   多部分边界。

通常，HTTP对多部分邮件正文的处理方式与此不同   任何其他媒体类型：严格作为有效载荷。唯一的例外是   当它出现在206中时，“multipart / byteranges”类型（附录19.2）   （部分内容）响应，将由某些HTTP解释   缓存机制，如第13.5.4和14.16节所述。在所有   在其他情况下，HTTP用户代理应该遵循相同或类似的   在收到多部分类型时，作为MIME用户代理的行为。   多部分消息的每个正文中的MIME头字段 -   除了他们定义的HTTP之外，body对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].

是否存在事实上或已确定的原因，为什么浏览器通常不支持多部分HTTP响应？

2 个答案: