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

Question

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

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

Чтобы быть предельно ясным, я не ищу мнения, но истинное свидетельство, указывающее, почему это может быть. Например, если Mozilla опубликовала что-то об этом несколько лет назад, или есть закрытый билет в трекер Firefox, где ведущий разработчик комментирует, почему они не будут реализовывать это.

Answer 1

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

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

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

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

Answer 2

непосредственно из самого (в http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2) W3 орг:

3.7.2 MULTIPART Типы

MIME предоставляет несколько типов «multipart» - инкапсуляции одного или нескольких объектов внутри одного тела сообщения. Все множественные типы используют общий синтаксис, как определено в разделе 5.1.1 RFC 2046

[40] и ДОЛЖНЫ включать параметр границы как часть значения типа носителя .Тело сообщения само является элементом протокола и ДОЛЖНЫ , поэтому используют только CRLF для представления разрывов строк между частями тела. В отличие от RFC 2046, эпилог любого многостраничного сообщения ДОЛЖЕН быть пустым; HTTP-приложения НЕ ДОЛЖНЫ передавать эпилог (даже если оригинальная копия содержит эпилог). Эти ограничения существуют в порядке , чтобы сохранить саморазграничивающий характер многочастного сообщения - тело, в котором «конец» тела сообщения обозначается кратной граничной границей конца .

В общем, HTTP обрабатывает многочастное тело сообщения не иначе, как любого другого типа носителя: строго как полезная нагрузка. Единственным исключением является тип «multipart/byteranges» (приложение 19.2), когда он появляется в ответе 206 (частичное содержимое), который будет интерпретироваться некоторыми механизмами кэширования HTTP , как описано в разделах 13.5.4 и 14.16. Во всех других случаях пользовательский агент 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].