para - ¿Existe una razón establecida o de facto por la que las respuestas HTTP de varias partes generalmente no son compatibles con los navegadores?

http/1.1 200 ok

Question

El protocolo HTTP ha soportado respuestas multiparte durante mucho tiempo. Los he usado antes para las API con consumidores apropiadamente equipados, pero no parece que el soporte del navegador sea muy bueno, ni ha mejorado en la última media década. He tenido dificultades para encontrar mucha información sobre por qué esto podría ser. Me encantaría poder reducir las solicitudes HTTP mediante el envío de todos los activos que sé que necesitará una aplicación web en la solicitud inicial, especialmente para aplicaciones que emplean marcos del lado del cliente como Backbone.js.

¿Hay documentos informativos, artículos comerciales, experimentos fallidos u otra evidencia de por qué ni los fabricantes de navegadores ni los evangelistas de rendimiento web están prestando atención a esta construcción HTTP de larga data?

Para ser completamente claro, no estoy buscando una opinión, sino una verdadera evidencia que indica por qué esto podría ser. Por ejemplo, si Mozilla publicó algo sobre esto hace unos años, o si hay un boleto cerrado en el rastreador de errores de Firefox donde un desarrollador principal comenta sobre por qué no lo implementarán.

Answer 1

Directamente desde la propia organización W3 (en http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2 ):

3.7.2 Tipos multiparte

MIME proporciona varios tipos "multiparte": encapsulaciones de una o más entidades dentro de un único cuerpo de mensaje. Todos los tipos multiparte comparten una sintaxis común, como se define en la sección 5.1.1 de RFC 2046

[40], y DEBE incluir un parámetro de límite como parte del valor del tipo de medio. El cuerpo del mensaje es en sí mismo un elemento de protocolo y, por lo tanto, DEBE usar solo CRLF para representar saltos de línea entre partes del cuerpo. A diferencia de RFC 2046, el epílogo de cualquier mensaje multiparte DEBE estar vacío; Las aplicaciones HTTP NO DEBEN transmitir el epílogo (incluso si el multiparte original contiene un epílogo). Estas restricciones existen para preservar la naturaleza autolimitadora de un cuerpo de mensaje de varias partes, en donde el "final" del cuerpo de mensaje se indica mediante el límite de múltiples partes que termina.

En general, HTTP trata un cuerpo de mensaje de varias partes de manera diferente a cualquier otro tipo de medio: estrictamente como carga útil. La única excepción es el tipo "multipart / byteranges" (apéndice 19.2) cuando aparece en una respuesta 206 (Contenido parcial), que será interpretada por algunos mecanismos de almacenamiento en caché HTTP como se describe en las secciones 13.5.4 y 14.16. En todos los demás casos, un agente de usuario HTTP DEBERÍA seguir el mismo comportamiento o similar al que un agente de usuario MIME haría al recibir un tipo de varias partes. Los campos de encabezado MIME dentro de cada parte del cuerpo de un cuerpo de mensaje de varias partes no tienen ningún significado para HTTP más allá de lo definido por su semántica MIME.

En general, un agente de usuario HTTP DEBERÍA seguir el mismo comportamiento o similar que un agente de usuario MIME al recibir un tipo de varias partes. Si una aplicación recibe un subtipo multiparte no reconocido, la aplicación DEBE tratarlo como equivalente a "multiparte / mixto".

  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].

Answer 2

En realidad, las versiones más antiguas de IE procesaban las respuestas de la aplicación multiparte / octeto y guardaban todos los archivos durante una operación de descarga, pero esto se eliminó recientemente (a partir de IE7, creo) y era específico para la descarga solamente.

Dudo que encuentres la "evidencia" que estás buscando, porque no creo que lo que propusiste esté de acuerdo con el "espíritu" de la especificación HTTP. Intentaré explicar lo que quiero decir con eso. El paradigma básico de HTTP es una solicitud dirigida por el cliente y la respuesta del servidor a esa solicitud. Pero parece que está proponiendo que el servidor devolvería archivos arbitrarios con el supuesto de que el cliente sabría qué hacer con ellos.

Sin embargo, si tuviera que proponer que el cliente primero solicite explícitamente varios archivos, entonces yo diría que podría estar en algo. La especificación HTTP 1.1 permite que el encabezado Aceptar solicitud de cliente indique compatibilidad con varias partes, por lo que parece ser la forma en que los diseñadores de HTTP imaginaron que esto funcionaría. Desafortunadamente, la especificación no dice cómo el cliente debe identificar los archivos que espera recibir, y esto es comprensible si observa HTTP en un vacío, como se define, en lugar de a través de la lente de los navegadores y sitios web. Ese es un detalle de implementación que se deja al cliente y al servidor para resolver. Es una preocupación que se aplica a una capa diferente: qué es el contenido y cómo se consume, en lugar de cómo solicitarlo y transportarlo.

Es fácil imaginar varias soluciones, por supuesto, pero sin un estándar para referirse, no parece justificar el esfuerzo por parte de los desarrolladores del navegador. Podría imaginar a alguien como Microsoft (con control sobre un servidor y navegador ampliamente adoptado) implementando esto, pero estarían inventando una especificación y la gente se quejaría. Aparentemente, hemos decidido que es mejor esperar 10 años para que el W3C acuerde algo ...