Transfer-Encoding: gzip vs. Content-Encoding: gzip

Qual é o estado atual das coisas quando se trata de fazer

Transfer-Encoding: gzip

ou um

Content-Encoding: gzip

quando desejo permitir que clientes com, por exemplo, largura de banda limitada, sinalizem sua disposição de aceitar uma resposta compactada e o servidor tenha a palavra final se deve compactar ou não .

O último é o que, por exemplo, o mod_deflate do Apache e o IIS fazem, se você permitir que ele cuide da compactação. Dependendo do tamanho do conteúdo a ser compactado, ele fará o adicional Transfer-Encoding: chunked.

Também incluirá um Vary: Accept-Encoding, que já indica o problema. Content-Encodingparece ser parte da entidade, portanto, alterar os Content-Encodingvalores para uma alteração da entidade, ou seja, um Accept-Encodingcabeçalho diferente significa, por exemplo, um cache não pode usar sua versão em cache da entidade idêntica de outra forma.

Existe uma resposta definitiva sobre isso que eu perdi (e que não está enterrada dentro de uma mensagem em uma longa discussão em algum grupo de notícias do Apache)?

Minha impressão atual é:

• A codificação de transferência seria, de fato, a maneira certa de fazer o que geralmente é feito com a codificação de conteúdo pelas implementações existentes de servidor e cliente
• A codificação de conteúdo, por causa de suas implicações semânticas, traz alguns problemas (o que o servidor deve fazer para ETagquando comprime uma resposta de forma transparente?)
• O motivo é frango'n'egg: os navegadores não suportam porque os servidores não, porque os navegadores não

Portanto, estou assumindo que o caminho certo seria um Transfer-Encoding: gzip(ou, se eu adicionalmente dividir o corpo, ele se tornaria Transfer-Encoding: gzip, chunked ). E não há razão para tocar em Varyou ETagou qualquer outro cabeçalho nesse caso, pois é uma coisa de nível de transporte.

Por enquanto, não me importo muito com o 'salto a salto' de Transfer-Encoding, algo que os outros parecem estar preocupados em primeiro lugar, porque os proxies podem descompactar e encaminhar descompactado para o cliente. No entanto, os proxies podem muito bem encaminhá-lo no estado em que se encontra (compactado), se a solicitação original tiver o Accept-Encodingcabeçalho adequado , o que, no caso de todos os navegadores que conheço, é um dado adquirido.

A propósito, esse problema já existe há pelo menos uma década, consulte, por exemplo, https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

Qualquer esclarecimento sobre isso será apreciado. Tanto em termos do que é considerado compatível com os padrões quanto do que é considerado prático. Por exemplo, as bibliotecas de cliente HTTP que suportam apenas "Codificação de conteúdo" transparente seriam um argumento contra a praticidade.

Citando Roy T. Fielding , um dos autores da RFC 2616:

alterar a codificação do conteúdo em tempo real de maneira inconsistente (nem "nunca" nem "sempre) torna impossível que solicitações posteriores relativas a esse conteúdo (por exemplo, PUT ou GET condicional) sejam tratadas corretamente. Este é, obviamente, o motivo do desempenho codificação de conteúdo em tempo real é uma ideia estúpida, e por isso adicionei Transfer-Encoding ao HTTP como a maneira adequada de fazer a codificação em tempo real sem alterar o recurso.

Fonte: https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

Em outras palavras: não faça a codificação de conteúdo em tempo real , use a codificação de transferência!

Editar: isto é, a menos que você queira servir conteúdo compactado com gzip para clientes que só entendem Content-Encoding . Que, infelizmente, parece ser a maioria deles. Mas esteja ciente de que você sai dos domínios da especificação e pode encontrar problemas como o mencionado por Fielding, bem como outros, por exemplo, quando proxies de cache estão envolvidos.

O uso correto , conforme definido no RFC 2616 e realmente implementado in the wild, é para o cliente enviar um Accept-Encodingcabeçalho de solicitação (o cliente pode especificar várias codificações). O servidor pode então, e somente então, codificar a resposta de acordo com as codificações suportadas pelo cliente (se os dados do arquivo ainda não estiverem armazenados nessa codificação), indicar no Content-Encodingcabeçalho da resposta qual codificação está sendo usada. O cliente pode então ler os dados do soquete com base no Transfer-Encoding(ou seja, chunked) e decodificá-los com base no Content-Encoding(ou seja:) gzip.

Portanto, no seu caso, o cliente enviaria um Accept-Encoding: gzipcabeçalho de solicitação e, em seguida, o servidor pode decidir compactar (se já não estiver) e enviar um Content-Encoding: gzipe, opcionalmente, um Transfer-Encoding: chunkedcabeçalho de resposta.

E sim, o Transfer-Encodingcabeçalho pode ser usado em solicitações, mas apenas para HTTP 1.1, o que requer que as implementações de cliente e servidor suportem a chunkedcodificação em ambas as direções.

ETagidentifica exclusivamente os dados de recursos no servidor, não os dados realmente sendo transmitidos. Se um determinado recurso de URL muda seu ETagvalor, significa que os dados do lado do servidor para esse recurso mudaram.