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
que no tiene cuerpo, indica el valor que se habr铆a aplicado al mensaje GET
correspondiente.
Header type | Response header |
---|---|
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
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.
Ver adem谩s:
Accept-Encoding
Content-Encoding
Content-Length
- Header fields that regulate the use of trailers:
TE
(requests) andTrailer
(responses).