La codificación por transferencia en fragmentos es un mecanismo de transferencia de datos en tiempo real disponible en el Protocolo de transferencia de hipertexto (HTTP) versión 1.1, definido en RFC 9112 §7.1. En la codificación por transferencia en fragmentos, 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. Tanto el emisor como el receptor no necesitan conocer en ningún momento el flujo de datos que se encuentra fuera del fragmento que se está procesando en ese momento.
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 chunked 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 y de todos modos aceptable, incluso si no se incluye en el campo de encabezado de solicitud TE (codificación de transferencia), y cuando se utiliza con otros mecanismos de transferencia, siempre se debe aplicar en último lugar a los datos transferidos y nunca más de una vez. Este método de codificación de transferencia también permite que se envíen 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 trailers de entidad adicionales incluso si el cliente no especificó la opción "trailers" 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 incluir sus nombres en el campo de encabezado Trailer; se prohíbe específicamente que aparezcan tres tipos de campos de encabezado como campo de trailer: Transfer-Encoding , Content-Length y Trailer .
Si se especifica un campo Transfer-Encoding con un valor de " chunked " 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 de terminación con un final opcional antes de la secuencia ␍␊ final (es decir, retorno de carro seguido de avance de línea ).
Cada fragmento comienza con la cantidad de octetos de los datos que incorpora expresados como un número hexadecimal en ASCII seguido de parámetros opcionales ( extensión de fragmento ) y una secuencia de terminación ␍␊, seguida de los datos del fragmento. El fragmento termina con ␍␊.
Si se proporcionan extensiones de fragmentos, el tamaño del fragmento termina con un punto y coma y va seguido de los parámetros, cada uno de ellos también delimitado por punto y coma. Cada parámetro se codifica como un nombre de extensión seguido de un signo igual y un valor opcionales. Estos parámetros se pueden utilizar para un resumen de mensaje en ejecución o una firma digital , o para indicar un progreso de transferencia estimado, por ejemplo.
El fragmento de terminación es un fragmento especial de longitud cero. Puede contener un finalizador, que consiste en 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 ser más eficiente determinarlos después de procesar toda la entidad del mensaje. En ese caso, es útil enviar esos encabezados en el finalizador.
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 la 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 se comprime primero y luego se fragmenta; por lo tanto, la codificación fragmentada en sí no se comprime y los datos de cada fragmento se comprimen individualmente. A continuación, el punto final remoto decodifica el flujo concatenando los fragmentos y descomprimiendo el resultado.
El siguiente ejemplo contiene tres fragmentos 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 anotada de los datos codificados.
4␍␊ (el tamaño del fragmento es de cuatro octetos) Wiki (cuatro octetos de datos) ␍␊ (final del fragmento)7␍␊ (el tamaño del fragmento es de siete octetos) pedia i (siete octetos de datos) ␍␊ (final del fragmento)B␍␊ (el tamaño del fragmento es de once octetos) n ␍␊fragmentos. (once octetos de datos) ␍␊ (final del fragmento)0␍␊ (el tamaño del fragmento es cero octetos, no hay 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.
Al decodificar el ejemplo anterior se obtienen los siguientes octetos:
Wikipedia en ␍␊fragmentos.
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 utilizarse en HTTP/2