Codificación de transferencia por fragmentos

La codificación de transferencia por 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 la RFC 9112 §7.1 . En este método, el flujo de datos se divide en una serie de fragmentos que no se superponen. Estos fragmentos se envían y reciben de forma independiente. En ningún momento dado, ni el emisor ni el receptor necesitan conocer el resto del flujo de datos, más allá del fragmento que se está procesando.

Cada fragmento va precedido de su tamaño en bytes y 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 por fragmentos 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 por bloques aportó diversas ventajas:

• La codificación de transferencia por fragmentos permite que un servidor mantenga una conexión HTTP persistente para contenido generado dinámicamente. En este caso, el encabezado HTTP Content-Length no se puede usar para delimitar el contenido y la siguiente solicitud/respuesta HTTP, ya que el tamaño del contenido aún se desconoce. La codificación por fragmentos tiene la ventaja de que no es necesario generar el contenido completo antes de escribir el encabezado, ya que permite la transmisión del contenido en fragmentos y la señalización explícita del final del contenido, dejando la conexión disponible para la siguiente solicitud/respuesta HTTP.
• La codificación por fragmentos permite al remitente enviar campos de encabezado adicionales después del cuerpo del mensaje. Esto es importante en casos donde los valores de un campo no se pueden conocer hasta que se haya generado el contenido, como cuando el contenido del mensaje debe firmarse digitalmente. Sin la codificación por fragmentos, el remitente tendría que almacenar en búfer el contenido hasta que estuviera completo para calcular el valor de un campo y enviarlo antes del contenido.

Para la versión 1.1 del protocolo HTTP, el mecanismo de transferencia por fragmentos se considera siempre aceptable, incluso si no aparece en el campo de encabezado de solicitud Transfer-Encoding (TE), y cuando se usa con otros mecanismos de transferencia, siempre debe aplicarse al final 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 un argumento del campo de solicitud TE. El servidor de origen de la respuesta también puede decidir enviar tráileres de entidad adicionales incluso si el cliente no especificó el parámetro "trailers", pero solo si los metadatos son opcionales (es decir, el cliente puede usar la entidad recibida sin ellos). Siempre que se usen los tráileres, el servidor debe listar sus nombres en el campo de encabezado Trailer; tres tipos de campos de encabezado están específicamente prohibidos para aparecer como un campo de tráiler: Content-Length , Trailer y Transfer-Encoding .

Si en un mensaje HTTP (ya sea una solicitud enviada por un cliente o la respuesta del servidor) se especifica un campo Transfer-Encoding con el valor " chunked ", el cuerpo del mensaje consta de uno o más fragmentos y un fragmento de terminación con un tráiler opcional antes de la secuencia final ␍␊ (es decir, retorno de carro seguido de salto de línea ).

Cada fragmento comienza con el número de octetos de los datos que contiene, expresado 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 finaliza con ␍␊.

Si se proporcionan extensiones de fragmento, el tamaño del fragmento finaliza con un punto y coma, seguido de los parámetros, cada uno también delimitado por punto y coma. Cada parámetro se codifica como un nombre de extensión seguido de un signo de igual opcional y un valor. Estos parámetros podrían utilizarse para un resumen de mensaje en ejecución o una firma digital , o para indicar el progreso estimado de la transferencia, por ejemplo.

El fragmento de terminación es un fragmento especial de longitud cero. Puede contener un tráiler, que consiste en una secuencia (posiblemente vacía) de campos de encabezado de entidad. Normalmente, estos 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 tráiler.

Los campos de encabezado que regulan el uso de los pies de página son Transfer-Encoding con el parámetro "trailers" (utilizado en las solicitudes) y Trailer (utilizado en las respuestas).

Los servidores HTTP suelen utilizar compresión para optimizar la transmisión, por ejemplo, con Content-Encoding: gzip o Content-Encoding: deflate . Si se habilitan tanto la compresión como la codificación por fragmentos, el flujo de contenido se comprime primero y luego se divide en fragmentos; por lo tanto, la codificación de los fragmentos en sí no se comprime, y los datos de cada fragmento se comprimen de forma integral (es decir, en función de todo el contenido). El servidor remoto decodifica el flujo concatenando los fragmentos y descomprimiendo el resultado.

• Lista de campos de encabezado HTTP

• "Codificación de transferencia por fragmentos" . HTTP/1.1 . IETF . Junio ​​de 2022. sec.  7.1. doi : 10.17487/RFC9112 . RFC 9112 .