Question

HTTP 协议长期以来一直支持多部分响应。我之前曾使用过这些响应来购买拥有适当装备的消费者的API, 但它似乎没有为它们提供很好的浏览器支持, 在过去的半个十年里也没有得到改善。我很难找到很多关于原因的信息。我很想通过发送我所知道的最初请求所需的所有资产来削减 HTTP 请求。特别是用于使用 Backbone. js 等客户端框架的应用程序。

是否有白纸、贸易文章、失败的实验或其他证据来证明为什么无论是浏览器制作者还是网络表演的福音派传教士都没有给予这种长期的HTTP关注?

要完全清楚, 我并不是在寻找意见, 而是真实的证据来说明原因。例如, 如果Mozilla几年前发表了一些关于这一点的文章, 或者在Firefox 错误追踪器里有一张关闭的罚单, 其中一位首席开发者会评论为什么他们不执行这一点。

Answer 1

实际上旧版本的 IE 将处理多部分应用程序/ octe- River 响应, 并在下载操作中保存所有文件, 但最近( IE 7 ) 被删除了, 仅用于下载。

我怀疑你是否会发现你正在寻找的“证据”, 因为我不认为你的提议符合 HTTP 规格的“ 精神 ” 。我会试着解释我的意思。 HTTP 的基本范例是客户驱动的请求和服务器对此请求的反应。但你似乎提议服务器会返回任意的文档, 假设客户知道如何处理这些文件。

但是,如果你建议客户首先明确要求多个文件, 那么我就会说您可能会有所作为。 HTTP 1. 1 规格允许接受客户请求信头显示多部分支持, 因此这似乎是 HTTP 设计师如何设想的。不幸的是, 该规格对于客户如何识别其预期收到的文件保持沉默, 如果您在真空中而不是通过浏览器和网站的透镜来查看 HTTP, 这是可以理解的。这是一个执行细节, 由客户和服务器来决定。这是一个适用于不同层次的问题, 内容是什么, 如何消耗, 而不是如何要求和传输它。

当然,想象各种解决方案是很容易的,但是如果没有标准可以参考,似乎不需要浏览器开发者的努力。我可以想象像微软这样的人(对一个被广泛采纳的服务器和浏览器拥有控制权 ), 实施这个计划, 但他们会发明一个规格,人们会抱怨。显然,我们决定等十年后W3C才能达成一致...

Answer 2

直接来自W3或g本身():

3.7.2 多部分类型

MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All multipart types share a common syntax, as defined in section 5.1.1 of RFC 2046

[40], and MUST include a boundary parameter as part of the media type value. The message body is itself a protocol element and MUST therefore use only CRLF to represent line breaks between body-parts. Unlike in RFC 2046, the epilogue of any multipart message MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve the self-delimiting nature of a multipart message- body, wherein the "end" of the message-body is indicated by the ending multipart boundary.

In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception is the "multipart/byteranges" type (appendix 19.2) when it appears in a 206 (Partial Content) response, which will be interpreted by some HTTP caching mechanisms as described in sections 13.5.4 and 14.16. In all other cases, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within each body-part of a multipart message- body do not have any significance to HTTP beyond that defined by their MIME semantics.

In general, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives an unrecognized multipart subtype, the application MUST treat it as being equivalent to "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].

友情链接