Существует ли фактическая или установленная причина, по которой многочастные HTTP-ответы обычно не поддерживаются в браузерах?

Протокол HTTP давно поддерживает многочастичные ответы. Я использовал их ранее для API с соответствующим образом оснащенными потребителями, но, похоже, их поддержка в браузерах не очень хорошая и не улучшилась за последние полвека. Мне было трудно найти много информации о том, почему это может быть. Мне бы хотелось иметь возможность сократить HTTP-запросы, отправив все ресурсы, которые, как я знаю, понадобится веб-приложению при первоначальном запросе, особенно для приложений, использующих клиентские инфраструктуры, такие как Backbone.js.

Существуют ли какие-либо технические документы, торговые статьи, неудачные эксперименты или другие доказательства того, почему ни создатели браузеров, ни евангелисты веб-производительности не уделяют этой давней конструкции HTTP никакого внимания?

To be utterly clear, I'm not looking for an opinion, but veritable evidence indicating why this might be. For example, if Mozilla published something about this a few years ago, or there is a closed ticket in the Firefox bug tracker where a lead developer comments about why they won't implement this.

Ответы на вопрос(2)

Решение Вопроса

ения / потока октетов и сохраняли все файлы во время операции загрузки, но это было недавно удалено (я думаю, что в IE7) и предназначалось только для загрузки.

Я сомневаюсь, что вы собираетесь найти "доказательства" вы ищете, потому что я не думаю, что то, что вы предложили, соответствует "духу" спецификации HTTP. Я постараюсь объяснить, что я имею в виду под этим. Основной парадигмой HTTP является запрос, управляемый клиентом, и ответ сервера на этот запрос. Но вы, похоже, предлагаете, чтобы сервер возвращал произвольные файлы, предполагая, что клиент будет знать, что с ними делать.

Однако, если бы вы предложили, чтобы клиент сначала явно запросил несколько файлов, я бы сказал, что вы можете что-то предпринять. Спецификация HTTP 1.1 позволяет в заголовке клиентского запроса Accept указывать поддержку нескольких частей, поэтому, похоже, именно так разработчики HTTP и предполагали эту работу. К сожалению, в спецификации ничего не говорится о том, как клиент должен идентифицировать файлы, которые он ожидает получить, и это понятно, если смотреть на HTTP в вакууме, как он определен, а не через призму браузеров и веб-сайтов. Это детали реализации, которые остаются на усмотрение клиента и сервера. Это проблема, которая относится к другому уровню - что такое контент и как он потребляется, а не как запрашивать его и транспортировать.

Разумеется, легко представить различные решения, но без стандарта, на который можно сослаться, это, по-видимому, не потребует усилий со стороны разработчиков браузеров. Я мог бы вообразить кого-то вроде Microsoft (контролирующего широко распространенный сервер и браузер), реализующего это, но он придумывает спецификацию, и люди будут жаловаться. По-видимому, мы решили, что лучше подождать 10 лет, чтобы W3C договорился о чем-то ...

 24 мая 2012 г., 20:33
Дело в том, что люди, которые пишут веб-браузеры, не просто спонтанно начинают предполагать, что многочастный ответ должен каким-то образом отображаться на то, что они в конечном итоге захотят. Это не то, как работает HTTP, но это то, что вы предлагаете.
 19 сент. 2016 г., 18:02

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2):

3.7.2 Multipart Types

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].
 29 июл. 2013 г., 07:16
Я ответил этим только потому, что недавно работал с запросами и ответами MIME XHR. Полагаю, что мой ответ на самом деле не касается вашего вопроса, кроме как сказать, что он, безусловно, является частью стандарта и что нет причин, по которым браузеры и серверы не должны поддерживать и соблюдать эту часть протокола.
 29 июл. 2013 г., 07:24
Что касается меня, у меня не было проблем с получением любого из браузеров, которые я использую (FF, Chrome / Chromium, Opera, IE), чтобы понимать и правильно обрабатывать запросы и ответы MIME.
 coreyward05 июл. 2013 г., 21:42
Это, по-видимому, не указывает на какие-либо ограничения на использование составных ответов.

Ваш ответ на вопрос