ACTUALIZACIÓN 10 de febrero de 2012:
zOompf ha completado una investigación muy exhaustiva sobre este mismo tema aquí . Supera cualquier hallazgo a continuación.
ACTUALIZACIÓN 11 de septiembre de 2010:
Se ha creado una plataforma de prueba para esto aquí
Definiciones HTTP 1.1 de GZIP y DEFLATE (zlib) para obtener información general:
"'Gzip' es el formato gzip, y 'deflate' es el formato zlib . Probablemente deberían haber llamado al segundo 'zlib' en su lugar para evitar confusiones con el formato de datos comprimidos sin formato deflate. Mientras que HTTP 1.1 RFC 2616 apunta correctamente a la especificación zlib en RFC 1950 para la codificación de transferencia 'desinflar', ha habido informes de servidores y navegadores que producen incorrectamente o esperan datos de desinflado sin procesar según la especificación de desinflado en RFC 1951, sobre todo productos de Microsoft . transferir la codificación utilizando el formato zlib sería el enfoque más eficiente ( y de hecho exactamente para lo que se diseñó el formato zlib), usar la codificación de transferencia 'gzip' es probablemente más confiable debido a una desafortunada elección de nombre por parte de los autores de HTTP 1.1 ". (fuente: http://www.gzip.org/zlib/zlib_faq.html )
Entonces, mi pregunta: si envío datos RAW desinflados sin envoltorio zlib (o gzip, para el caso), ¿hay navegadores modernos (por ejemplo, IE6 y superiores, FF, Chrome, Safari, etc.) que NO puedan entender el desinflado sin procesar datos comprimidos (asumiendo que el encabezado de solicitud HTTP "Accept-Encoding" contiene "deflate")?
Los datos desinflados SIEMPRE serán unos pocos bytes más pequeños que GZIP.
Si todos estos navegadores pueden decodificar con éxito los datos, ¿qué desventajas hay en enviar RAW deflate en lugar de zlib?