Deflate a compatibilidade e as vantagens do navegador de compressão sobre o GZIP
-
21-09-2019 - |
Pergunta
Atualização 10 de fevereiro de 2012:
Zoompf concluiu algumas pesquisas muito minuciosas sobre este tópico aqui. Isso supera quaisquer descobertas abaixo.
Atualização 11 de setembro de 2010:
Uma plataforma de teste foi criada para isso aqui
HTTP 1.1 Definições de Gzip e Deflate (ZLIB) Para algumas informações básicas:
"'Gzip' é o formato GZIP e 'Deflate' é o formato Zlib. Eles provavelmente deveriam ter chamado o segundo de 'zlib' para evitar confusão com o formato de dados comprimido de deflate bruto. Enquanto o HTTP 1.1 RFC 2616 aponta corretamente para a especificação do ZLIB no RFC 1950 para a codificação de transferência 'Deflate', Houve relatos de servidores e navegadores que produzem ou esperam incorretamente os dados de deflatar brutos de acordo com a especificação de deflate na RFC 1951, principalmente os produtos da Microsoft. Portanto, mesmo que a codificação de transferência 'deflate' usando o formato Zlib seja a abordagem mais eficiente (E de fato exatamenteo que o formato Zlib foi projetado para), o uso da codificação de transferência 'GZIP' é provavelmente mais confiável devido a uma escolha infeliz de nome por parte dos autores HTTP 1.1. "(Fonte: http://www.gzip.org/zlib/zlib_faq.html)
Então, minha pergunta: se eu enviar dados de deflatar brutos sem invólucro zlib (ou gzip, nesse caso), existem navegadores modernos (por exemplo, ie6 e up, ff, cromo, safari, etc.) que não conseguem entender o esvaziar bruto Dados compactados (assumindo o cabeçalho da solicitação HTTP "Acepcoding" contém "deflatar")?
A deflate os dados sempre serão alguns bytes menores que o GZIP.
Se todos esses navegadores puderem decodificar com sucesso os dados, que desvantagens existem para o envio de deflate bruto em vez de Zlib?
Atualização 11 de setembro de 2010:
Uma plataforma de teste foi criada para isso aqui
Solução
ATUALIZAÇÃO: Os navegadores estão lançando suporte para deflatar bruto. Zoompf concluiu algumas pesquisas muito minuciosas sobre este tópico aqui. Infelizmente, parece que o deflate bruto não é seguro de usar.
Verificar http://www.vervestudios.co/projects/compression-tests/results Para mais resultados.
Aqui estão os navegadores que foram testados:
/* Browser DEFLATE ZLIB */
XP Internet Explorer 6 PASS FAIL
XP Internet Explorer 7 PASS FAIL
XP Internet Explorer 8 PASS FAIL
Vista Internet Explorer 8 PASS FAIL
XP Firefox 3.6.* PASS PASS
XP Firefox 3.5.3 PASS PASS
XP Firefox 3.0.14 PASS PASS
Win 7 Firefox 3.6.* PASS PASS
Vista Firefox 3.6.* PASS PASS
Vista Firefox 3.5.3 PASS PASS
XP Safari 3 PASS PASS
XP Safari 4 PASS PASS
XP Chrome 3.0.195.27 PASS PASS
XP Opera 9 PASS PASS
XP Opera 10 PASS PASS
XP Sea Monkey 1.1.8 PASS PASS
Android 1.6 Browser (v4)* N/A N/A
OS-X Safari 4 PASS PASS
OS X Chrome 7.0.517.44 PASS PASS
OS X Opera 10.63 PASS PASS
iPhone 3.1 Safari PASS PASS
* O Android envia o cabeçalho da solicitação HTTP "Acepção de aceitação: GZIP". Deflate não é permitido.
Concluo que podemos sempre envie cru Esvaziar (quando o cabeçalho da solicitação HTTP "aceitar-se-codificar" contém "deflatar") e o navegador poderá interpretar corretamente os dados codificados. Alguém pode provar isso errado?
Nota: A implementação nativa do .NET de deflate (System.io.compression.deflatestream) é um deflate bruto. Também é péssimo. Por favor, use zlib.net Para todas as suas necessidades de esvaziamento .NET.
Outras dicas
O navegador Android 1.6 (V4) falha tanto o ZLIB quanto o teste deflate na sua página. Eu o adicionei à sua lista.
Não é o caso que AddOutputFilterByType DEFLATE
Usando mod_deflate envia por gzip por padrão?
Até onde eu sei, sim - praticamente você "sempre pode enviar deflatar cru e tudo ficaria bem" ... não há "sempre", mas acima de todos os casos. Caso contrário, esse é o problema do navegador.