Movatterモバイル変換


[0]ホーム

URL:


  1. Tecnologia Web para desenvolvedores
  2. HTTP
  3. Reference
  4. Cabeçalhos HTTP
  5. Transfer-Encoding

Esta página foi traduzida do inglês pela comunidade.Saiba mais e junte-se à comunidade MDN Web Docs.

View in EnglishAlways switch to English

Transfer-Encoding

Baseline Widely available

This feature is well established and works across many devices and browser versions. It’s been available across browsers since ⁨julho de 2015⁩.

O cabeçalhoTransfer-Encoding especifica a forma de codificação usada para transferir seguramente o corpo da mensagem (payload body) para o usuário.

Nota:HTTP/2 não suporta o mecanismo de codificação de trasferência fragmentada do HTTP 1.1, já que ele provém o próprio, e mais eficiente, mecanismo parastreaming de dados.

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 valoresTransfer-Encoding. Se você quer comprimir dados através da conexão inteira, use o cabeçalhoContent-Encoding ao invés disso.

Quando presente em uma resposta para uma requisiçãoHEAD que não tem corpo, ele indica o valor que seria aplicado a mensagemGET correspondente.

Tipo de cabeçalhoResponse header
Forbidden header namesim

Sintaxe

Transfer-Encoding: chunkedTransfer-Encoding: compressTransfer-Encoding: deflateTransfer-Encoding: gzipTransfer-Encoding: identity// Diversos valores podem ser listados, separados por vírgulaTransfer-Encoding: gzip, chunked

Diretivas

chunked

Dados enviados em uma série de fragmentos. O cabeçalhoContent-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 algoritmoLempel-Ziv-Welch (LZW). O nome do valor foi pego do programa UNIXcompress, 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 estruturazlib (definida naRFC 1950), com o algoritmo de compressãodeflate (definido emRFC 1951).

gzip

O formato usando acodificação Lempel-Ziv (LZ77), com CRC 32-bit. Este é originalmente o formato do programa UNIXgzip. O padrão HTTP/1.1 também recomenda que os servidores que suportem esta codificação de conteúdo devem reconhecerx-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). Estetoken, 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 OKContent-Type: text/plainTransfer-Encoding: chunked7\r\nMozilla\r\n9\r\nDeveloper\r\n7\r\nNetwork\r\n0\r\n\r\n

Especificações

EspecificaçãoTítulo
RFC 7230, sessão 3.3.1: Transfer-EncodingHypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

Compatibilidade com navegadores

Veja também

Help improve MDN

Learn how to contribute

This page was last modified on byMDN contributors.


[8]ページ先頭

©2009-2025 Movatter.jp