Transfer-Encoding

El encabezado Transfer-Encoding especifica la forma de codificaci贸n utilizada para transferir de forma segura el cuerpo del payload (en-US) al usuario.
HTTP/2 no admite el mecanismo de codificaci贸n de transferencia fragmentada de HTTP 1.1, ya que proporciona sus propios mecanismos, m谩s eficientes, para la transmisi贸n de datos.

Transfer-Encoding es un encabezado salto por salto, que se aplica a un mensaje entre dos nodos, no a un recurso en s铆 mismo. Cada segmento de una conexi贸n de m煤ltiples nodos puede usar diferentes valores de Transfer-Encoding. Si desea comprimir datos en toda la conexi贸n, use el encabezado de extremo a extremo Content-Encoding en su lugar.

Cuando est谩 presente en una respuesta a una solicitud HEAD (en-US) que no tiene cuerpo, indica el valor que se habr铆a aplicado al mensaje GET correspondiente.

Header type Response header (en-US)
Forbidden header name yes

Sintaxis

Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

// Se pueden enumerar varios valores, separados por una coma
Transfer-Encoding: gzip, chunked

Directivas

chunked
Los datos se env铆an en una serie de fragmentos. El encabezado Content-Length se omite en este caso y al comienzo de cada fragmento debe agregar la longitud del fragmento actual en formato hexadecimal, seguido de '\r\n' y luego el trozo en s铆, seguido de otro '\r\n'. El trozo de terminaci贸n es un trozo regular, con la excepci贸n de que su longitud es cero. Le sigue el avance, que consiste en una secuencia (posiblemente vac铆a) de campos de encabezado de entidad.
compress
Un formato usando el algoritmo Lempel-Ziv-Welch (LZW). El nombre del valor se tom贸 del programa de compresi贸n UNIX, que implement贸 este algoritmo.
Al igual que el programa de compresi贸n, que ha desaparecido de la mayor铆a de las distribuciones de UNIX, esta codificaci贸n de contenido no es utilizada por casi ning煤n navegador en la actualidad, en parte debido a un problema de patente (que expir贸 en 2003).
deflate
Usando la estructura zlib (definida en la RFC 1950), con el algoritmo de compresi贸n deflate (definido en la RFC 1951).
gzip
Un formato usando la codificaci贸n Lempel-Ziv (LZ77), con un CRC de 32 bits. Este es originalmente el formato del programa gzip de UNIX. El est谩ndar HTTP / 1.1 tambi茅n recomienda que los servidores que admiten esta codificaci贸n de contenido deben reconocer como un alias x-gzip, para fines de compatibilidad.
identity
Indica la funci贸n de identidad (es decir, sin compresi贸n ni modificaci贸n). Este token, excepto si se especifica expl铆citamente, siempre se considera aceptable.

Ejemplos

Codificaci贸n Fragmentada

La codificaci贸n fragmentada es 煤til cuando se env铆an grandes cantidades de datos al cliente y el tama帽o total de la respuesta puede no conocerse hasta que la solicitud se haya procesado por completo. Por ejemplo, al generar una tabla HTML grande como resultado de una consulta a la base de datos o al transmitir im谩genes grandes. Veamos un ejemplo de una respuesta fragmentada:

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n

Especificaciones

Especificaci贸n T铆tulo
RFC 7230, section 3.3.1: Transfer-Encoding Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

Compatibilidad con el Navegador

BCD tables only load in the browser

Ver adem谩s: