O cabeçalho Transfer-Encoding
especifica a forma de codificação usada para transferir seguramente o corpo da mensagem (payload body) para o usuário.
Transfer-Encoding
é um cabeçalho salto-por-salto (hop-by-hop header), que é aplicado a uma mensagem entre dois nós, não ao recurso em si. Cada segmento da conexão multi-nós pode usar diferentes valores Transfer-Encoding
. Se você quer comprimir dados através da conexão inteira, use o cabeçalho Content-Encoding
ao invés disso.
Quando presente em uma resposta para uma requisição HEAD
que não tem corpo, ele indica o valor que seria aplicado a mensagem GET
correspondente.
Tipo de cabeçalho | Response header |
---|---|
Forbidden header name | sim |
Sintaxe
Transfer-Encoding: chunked Transfer-Encoding: compress Transfer-Encoding: deflate Transfer-Encoding: gzip Transfer-Encoding: identity // Diversos valores podem ser listados, separados por vírgula Transfer-Encoding: gzip, chunked
Diretivas
chunked
- Dados enviados em uma série de fragmentos. O cabeçalho
Content-Length
é omitido neste caso e no começo de cada fragmento, você precisa adicionar o tamanho do fragmento atual em formato hexadecimal, seguido por '\r\n
' e o fragmento em si, seguido por outro '\r\n
'. O fragmento final é um fragmento normal, com exceção que seu tamanho é zero. Ele é seguido por um reboque, que consiste de uma (possívelmente vazia) sequência de cabeçalhos de entidade. compress
- Um formato usando o algoritmo Lempel-Ziv-Welch (LZW). O nome do valor foi pego do programa UNIX compress, que implementa o algoritmo.
Como o programa de compressão, que desapareceu da maioria das distribuições UNIX, esta codificação de conteúdo não é usada por quase nenhum navegador atualmente, em partes por causa do seu problema de patente (que expirou em 2003). deflate
- Usando a estrutura zlib (definida na RFC 1950), com o algoritmo de compressão deflate (definido em RFC 1951).
gzip
- O formato usando a codificação Lempel-Ziv (LZ77), com CRC 32-bit. Este é originalmente o formato do programa UNIX gzip. O padrão HTTP/1.1 também recomenda que os servidores que suportem esta codificação de conteúdo devem reconhecer
x-gzip
como um pseudônimo, para propósitos de compatibilidade. identity
- Indica a função de identidade (i.e. sem compressão, nem modificação). Este token, exceto se explicitamente especificado, é sempre considerado aceitável.
Exemplos
Codificação fragmentada
Codificação fragmentada é útil quando grandes quantidade de dados estão sendo enviados para o cliente e o tamanho total da resposta pode não ser conhecido até que a requisição seja totalmente processada. Por exemplo, quando gerando uma grande tabela HTML resultante de uma consulta no banco de dados ou transmitindo grandes imagens. A resposta fragmentada se parece com isto:
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
Especificações
Especificação | Título |
---|---|
RFC 7230, sessão 3.3.1: Transfer-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
Compatibilidade de 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.
Veja também
Accept-Encoding
Content-Encoding
Content-Length
- Cabeçalho que regulam o uso de reboques:
TE
(requisições) eTrailer
(respostas).