La codificación de transferencia por fragmentos (en inglés: Chunked Transfer Encoding) es un mecanismo de transferencia de datos disponible en el Protocolo de transferencia de hipertexto (HTTP) versión 1.1, y definido en RFC 9112 §7.1. Consiste en dividir el flujo de datos en una serie de "fragmentos", que se envían y reciben de forma independiente unos de otros. En ningún momento dado, ni el remitente ni el receptor necesitan conocer el flujo de datos que se encuentra fuera del fragmento que se está procesando en ese momento.

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 la cabecera Transfer-Encoding se utiliza para indicar este tipo de 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.

Razón fundamental La introducción de la codificación por fragmentos tiene diversas ventajas:

La codificación de transferencia por fragmentos permite que un servidor mantenga una conexión HTTP persistente para los contenidos generados dinámicamente. En este caso, el encabezado HTTP Content-Length no se utiliza para delimitar el contenido, ya que se desconoce el tamaño del contenido. La codificación por fragmentos tiene la ventaja de que no es necesario generar el contenido completo antes de escribir las cabeceras, ya que al permitir la transmisión del contenido en fragmentos, la señalización explícita del final del contenido deja la conexión disponible para la siguiente solicitud/respuesta HTTP. La codificación por fragmentos permite al remitente enviar cabeceras adicionales después del cuerpo del mensaje. Esto es importante en los casos en que no se pueden conocer los valores de un campo hasta que se haya generado el contenido, como por ejemplo 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 poder calcular el valor de un campo y enviarlo antes que el contenido.

Aplicabilidad 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 utiliza 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 enviar cabeceras adicionales después del último fragmento si el cliente especificó el parámetro "trailers" como 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 esos tráileres son opcionales (es decir, el cliente puede usar la entidad recibida sin ellos). Siempre que se utilicen 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 .

Formato Si un campo con un valor de se especifica 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 tráiler opcional antes de la secuencia final ␍␊ (retorno de carro seguido de salto de línea).

Cada fragmento comienza con la longitud en 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 termina 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 tiempo real o una firma digital, o para indicar un progreso estimado de la transferencia, por ejemplo.

El fragmento final es un fragmento especial de longitud cero. Puede contener un pie de página, que consiste en una secuencia (posiblemente vacía) de cabeceras. Normalmente, estas cabeceras se enviarían al inicio del mensaje; sin embargo, puede ser más eficiente determinarlos después de procesar la entidad completa del mensaje. En ese caso, es útil enviar esas cabeceras en el tráiler.

Las cabeceras 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).

Utilizar con compresión Los servidores HTTP suelen utilizar compresión para optimizar la transmisión, por ejemplo con o . Si tanto la compresión como la codificación por fragmentos están habilitadas, el flujo de contenido primero se comprime y luego se divide en fragmentos. Por tanto, la codificación de fragmentos en sí no se comprime, y los datos en cada fragmento se comprimen de forma integral (es decir, en función de todo el contenido). A continuación, el recetor decodifica el flujo concatenando los fragmentos y descomprimiendo el resultado.

Ejemplo

Datos codificados El siguiente ejemplo contiene tres fragmentos de datos de tamaño 4, 7 y 11 (en hexadecimal: "B") octetos.4␍␊Wiki␍␊7␍␊pedia e␍␊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) ␍␊ (fin del fragmento)

7␍␊ (el tamaño del fragmento es de siete octetos) pedia e (siete octetos de datos) ␍␊ (fin del fragmento)

B␍␊ (el tamaño del fragmento es de once octetos) n ␍␊trozos. (once octetos de datos) ␍␊ (fin del fragmento)

0␍␊ (el tamaño del fragmento es de cero octetos, no hay más fragmentos) ␍␊ (fin del último fragmento con cero octetos de datos) Nota: El tamaño de cada fragmento excluye los dos bytes ␍␊ que finalizan los datos de cada fragmento.

Datos decodificados Al decodificar el ejemplo anterior se obtienen los siguientes octetos:Wikipedia en ␍␊trozos.Los bytes anteriores se muestran normalmente comoWikipedia in chunks.

Véase también

Lista de campos de encabezado HTTP

Referencias

Enlaces externos

Categoría:Gestión de datos Categoría:Wikipedia:Páginas con traducciones sin revisar