Codificación de transferencia fragmentada

Codificación de transferencia fragmentada es un mecanismo de transferencia de datos en la versión 1.1 de la Hypertext Transfer Protocol (HTTP) en que los datos se envían en una serie de "pedazos". Utiliza el Codificación de transferencia Encabezado HTTP en lugar de la Content-Length encabezado, que de lo contrario requeriría que la versión anterior del protocolo. Porque no se utiliza el encabezado Content-Length, el remitente no necesita saber la longitud del contenido antes de que empieza a transmitir una respuesta al receptor. Los remitentes pueden comience a transmitir contenido generado dinámicamente antes de saber el tamaño total de ese contenido.

El tamaño de cada fragmento es enviado ante el pedazo sí mismo así que el receptor puede decir cuando ha terminado de recibir datos de ese fragmento. La transferencia de datos es terminada por un trozo final de longitud cero.

Una forma temprana de la codificación fragmentada se propuso en 1994. Más tarde lo fue estandarizada en HTTP 1.1.

Análisis razonado

La introducción de chunked encoding proporciona varias ventajas:

• Codificación de transferencia fragmentada permite que un servidor mantener un Conexión persistente de HTTP para el contenido generado dinámicamente. En este caso el encabezado HTTP Content-Length no puede utilizarse para delimitar el contenido y la siguiente petición/respuesta HTTP, como el tamaño del contenido aún se desconoce. Chunked encoding tiene la ventaja que no es necesario generar el contenido completo antes de escribir el encabezado, que permite streaming de contenido como pedazos y explícitamente señalando el final de los contenidos, haciendo la conexión disponible para la siguiente petición/respuesta HTTP.
• Chunked encoding permite al remitente enviar a los campos de encabezado adicional después el cuerpo del mensaje. Esto es importante en casos donde los valores de un campo no pueden ser conocidos hasta que el contenido ha sido producido como cuando el contenido del mensaje debe ser firmado digitalmente. Sin codificación fragmentada, el remitente tendría que amortiguar el contenido hasta que se completa con el fin de calcular el valor de un campo y lo envía antes del contenido.
• A veces utilizan servidores HTTP compresión (gzip o desinflar métodos) para optimizar la transmisión. La interacción entre fragmentados y gzip codificación es dictado por la codificación de dos etapas de HTTP: primero la secuencia de contenido está codificada como ()Content-Encoding: gzip), después de que la secuencia de bytes resultante está codificada para la transferencia usando otro codificador (Transfer-Encoding: chunked). Esto significa que en caso de compresión y codificación fragmentada están habilitados, el trozo de codificación propia no está comprimido tanto los datos de cada fragmento no deben estar comprimidos individualmente. El extremo remoto puede decodificar la secuencia de entrada la primera descodificación con el Transfer-Encoding, seguida de la codificación de contenido especificada.

Aplicabilidad

Para la versión 1.1 del protocolo HTTP, es considerado el mecanismo de transferencia fragmentada a aceptarse siempre y de todos modos, incluso si no aparece en la TE campo de encabezado de solicitud (codificación de transferencia), y cuando se utiliza con otros mecanismos de transferencia, debe siempre ser última aplicada a los datos transferidos y nunca más de una vez. Este método de codificación también la transferencia permite entidad adicional campos de encabezado ser enviados después del último pedazo si el cliente especifica el parámetro "acoplados" como argumento del campo TE. El servidor de origen de la respuesta también puede decidir enviar remolques adicionales entidad incluso si el cliente no especificó la opción "trailers" en el campo de la petición de TE, pero sólo si los metadatos están opcional (es decir, el cliente puede utilizar la entidad recibió sin ellos). Siempre que se utilicen los acoplados, el servidor debe listar sus nombres en el campo de encabezado remolque; 3 tipos de campo encabezado específicamente prohibidos de aparecer como un campo de remolque: Codificación de transferencia, Content-Length y Remolque.

Formato

Si un Codificación de transferencia campo con un valor de"fragmentados"se especifica en un mensaje HTTP (ya sea una solicitud enviada por un cliente o la respuesta del servidor), el cuerpo del mensaje consiste en un número no especificado de trozos, un trozo de terminación, remolque y una secuencia CRLF final (es decir, retorno de carro seguido por salto de línea).

Cada fragmento comienza con el número de octetos los datos incrusta expresada como un hexadecimal número en ASCII seguido de los parámetros opcionales)pedazo de extensión) y una terminación secuencia CRLF, seguido por el pedazo de datos. El pedazo es terminado por CRLF.

Si las extensiones pedazo son proporcionadas, el tamaño es terminado por un punto y coma y seguido de los parámetros, cada uno también delimitada por punto y coma. Cada parámetro se codifica como un extensión el nombre seguido de un signo igual opcional y valor. Estos parámetros podrían ser utilizados para un funcionamiento Resumen de mensaje o firma digital, o para indicar un avance Estimado transferencia, por ejemplo.

El trozo de terminación es un trozo regular, con la excepción de que su longitud es de cero. Es seguido por la caravana, que consiste en una secuencia (posiblemente vacía) de los campos de encabezado de entidad. Normalmente, estos campos de cabecera sería enviados en el encabezado del mensaje; Sin embargo, puede ser más eficaz para determinarlos después de procesar la entidad todo el mensaje. En ese caso, es útil enviar las cabeceras en el remolque.

Son campos de encabezado que regulan el uso de remolques TE (utilizado en las solicitudes), y Remolques (utilizado en las respuestas).

Ejemplo

Datos codificados

En el ejemplo siguiente, cada segunda línea es el comienzo de un nuevo trozo, con el tamaño de la porción como un número hexadecimal seguido \r\n como un separador de línea.

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
e\r\n
 in\r\n\r\nchunks.\r\n
0\r\n

Nota: el tamaño indica el tamaño de sólo los datos del pedazo. Esto no incluye el CRLF se arrastra ("\r\n") al final de los personajes contados. En este caso particular, los siguientes CRLF "en" se contaron 2 hacia la longitud del trozo de 0xE (14), y el CRLF en su propia línea también es contado 2 hacia la longitud del trozo de 0xE (14). El carácter período al final de "trozos" es el personaje 14, así es el último carácter de la porción de longitud 0xE (14). El CRLF tras el período es el CRLF se arrastra, así que no se cuenta hacia la longitud del trozo de 0xE (14).

Datos decodificados

Copro en trozos.

Véase también

• Lista de los campos de encabezado HTTP

Referencias

• Ver RFC 7230 sección 4.1 para obtener más información.

Otras Páginas

• Kopargaon (distrito electoral Vidhan Sabha)
• Ataque de inferencia
• Efecto de la gran hambruna en la economia estadounidense
• W el. Mark Lanier (abogados de Texas categoria)