La codificación de transferencia fragmentada es un mecanismo de transferencia de datos en streaming disponible en la versión 1.1 del Protocolo de transferencia de hipertexto (HTTP), definido en RFC 9112 §7.1. En la codificación de transferencia fragmentada, el flujo de datos se divide en una serie de "fragmentos" que no se superponen. Los fragmentos se envían y reciben de forma independiente unos de otros. Ni el remitente ni el receptor necesitan ningún conocimiento del flujo de datos fuera del fragmento que se está procesando actualmente en un momento dado.
Cada fragmento está precedido por su tamaño en bytes. La transmisión finaliza cuando se recibe un fragmento de longitud cero. La palabra clave fragmentada en el encabezado Transfer-Encoding se utiliza para indicar una transferencia fragmentada.
La codificación de transferencia fragmentada no es compatible con HTTP/2 , que proporciona sus propios mecanismos para la transmisión de datos. [1]
La introducción de la codificación fragmentada proporcionó varios beneficios:
Para la versión 1.1 del protocolo HTTP, el mecanismo de transferencia fragmentada se considera siempre aceptable, incluso si no figura en el campo del encabezado de solicitud TE (codificación de transferencia), y cuando se utiliza con otros mecanismos de transferencia, siempre debe aplicarse en último lugar. los datos transferidos y nunca más de una vez. Este método de codificación de transferencia también permite enviar campos de encabezado de entidad adicionales después del último fragmento si el cliente especificó el parámetro "trailers" como argumento del campo TE. El servidor de origen de la respuesta también puede decidir enviar avances de entidad adicionales incluso si el cliente no especificó la opción "avances" en el campo de solicitud TE, pero solo si los metadatos son opcionales (es decir, el cliente puede usar la entidad recibida sin ellos). ). Siempre que se utilicen los trailers, el servidor debe enumerar sus nombres en el campo de encabezado del Trailer; Se prohíbe específicamente que tres tipos de campos de encabezado aparezcan como campos de avance: Transfer-Encoding , Content-Length y Trailer .
Si se especifica un campo Transfer-Encoding con un valor de " fragmentado " en un mensaje HTTP (ya sea una solicitud enviada por un cliente o la respuesta del servidor), el cuerpo del mensaje consta de uno o más fragmentos y un fragmento final. con un avance opcional antes de la secuencia ␍␊ final (es decir, retorno de carro seguido de avance de línea ).
Cada fragmento comienza con el número de octetos de los datos que incorpora expresados como un número hexadecimal en ASCII seguido de parámetros opcionales ( extensión del fragmento ) y una secuencia ␍␊ de terminación, seguida de los datos del fragmento. El fragmento termina en ␍␊.
Si se proporcionan extensiones de fragmentos, el tamaño del fragmento termina con un punto y coma y le siguen los parámetros, cada uno también delimitado por punto y coma. Cada parámetro está codificado como un nombre de extensión seguido de un signo igual y un valor opcionales. Estos parámetros podrían usarse para un resumen de mensaje en ejecución o una firma digital , o para indicar un progreso de transferencia estimado, por ejemplo.
El fragmento final es un fragmento especial de longitud cero. Puede contener un final, que consta de una secuencia (posiblemente vacía) de campos de encabezado de entidad. Normalmente, dichos campos de encabezado se enviarían en el encabezado del mensaje; sin embargo, puede resultar más eficaz determinarlos después de procesar toda la entidad del mensaje. En ese caso, es útil enviar esos encabezados en el avance.
Los campos de encabezado que regulan el uso de trailers son TE (usados en solicitudes) y Trailers (usados en respuestas).
Los servidores HTTP suelen utilizar compresión para optimizar la transmisión, por ejemplo con Content-Encoding: gzip o Content-Encoding: deflate . Si tanto la compresión como la codificación fragmentada están habilitadas, el flujo de contenido primero se comprime y luego se fragmenta; por lo tanto, la codificación del fragmento en sí no se comprime y los datos de cada fragmento se comprimen individualmente. Luego, el punto final remoto decodifica la transmisión concatenando los fragmentos y descomprimiendo el resultado.
El siguiente ejemplo contiene tres fragmentos de octetos de datos de tamaño 4, 7 y 11 (hexadecimal "B").
4␍␊Wiki␍␊7␍␊pedia i␍␊B␍␊n ␍␊trozos.␍␊0␍␊␍␊
A continuación se muestra una versión comentada de los datos codificados.
4␍␊ (el tamaño del fragmento es de cuatro octetos) Wiki (cuatro octetos de datos) ␍␊ (fin del fragmento)7␍␊ (el tamaño del fragmento es siete octetos) pedia i (siete octetos de datos) ␍␊ (fin del fragmento)B␍␊ (el tamaño del fragmento es once octetos) n ␍␊fragmentos. (once octetos de datos) ␍␊ (fin del fragmento)0␍␊ (el tamaño del fragmento es cero octetos, no más fragmentos) ␍␊ (fin del fragmento final con cero octetos de datos)
Nota: El tamaño de cada fragmento excluye los dos ␍␊ bytes que terminan los datos de cada fragmento.
Decodificar el ejemplo anterior produce los siguientes octetos:
Wikipedia en ␍␊ trozos.
Los bytes anteriores normalmente se muestran como
Wikipedia entrozos.
HTTP/2 utiliza tramas de DATOS para transportar cargas útiles de mensajes. La codificación de transferencia fragmentada definida en la Sección 7.1 de [HTTP/1.1] NO DEBE usarse en HTTP/2