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

Question

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

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

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

Answer 1

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

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

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

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