ATUALIZAÇÃO em 10 de fevereiro de 2012:
zOompf concluiu algumas pesquisas muito completas sobre este mesmo tópico aqui . Ele supera qualquer descoberta abaixo.
ATUALIZAÇÃO 11 de setembro de 2010:
Uma plataforma de teste foi criada para isso aqui
Definições HTTP 1.1 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 compactados de deflate bruto. Enquanto o HTTP 1.1 RFC 2616 aponta corretamente para a especificação zlib no RFC 1950 para a codificação de transferência 'deflate', houve relatos de servidores e navegadores que produzem incorretamente ou esperam dados deflate brutos de acordo com a especificação deflate no RFC 1951, mais notavelmente produtos da Microsoft . Portanto, embora o 'deflate' codificação de transferência usando o formato zlib seria a abordagem mais eficiente ( e de fato exatamente para o que o formato zlib foi projetado), usar a codificação de transferência 'gzip' é provavelmente mais confiável devido a uma escolha infeliz de nome por parte dos autores do HTTP 1.1. "(fonte: http://www.gzip.org/zlib/zlib_faq.html )
Então, minha pergunta: se eu enviar dados de deflate RAW SEM wrapper zlib (ou gzip, nesse caso), existem navegadores modernos (por exemplo, IE6 e superior, FF, Chrome, Safari, etc) que NÃO conseguem entender o deflate bruto dados compactados (assumindo que o cabeçalho de solicitação HTTP "Aceitar-Codificação" contém "deflate")?
Os dados de esvaziamento SEMPRE serão alguns bytes menores do que GZIP.
Se todos esses navegadores puderem decodificar os dados com sucesso, quais são as desvantagens de enviar RAW deflate em vez de zlib?