ACTUALIZACIÓN del 10 de febrero de 2012:

zOompf ha completado una investigación exhaustiva sobre este temaaquí. Se supera cualquier hallazgo a continuación.

ACTUALIZACIÓN 11 de septiembre 2010:Se ha creado una plataforma de prueba para esto.aquí

Las definiciones HTTP 1.1 de GZIP y DEFLATE (zlib) para obtener información de fondo:

"'Gzip' es el formato gzip, y'desinflar' es el formato zlib. Probablemente deberían haber llamado al segundo 'zlib' para evitar confusiones con el formato de datos comprimidos de deflate sin formato. Mientras que el HTTP 1.1 RFC 2616 apunta correctamente a la especificación zlib en RFC 1950 para la codificación de transferencia 'deflactada',ha habido informes de servidores y navegadores que producen o esperan incorrectamente datos de desinflado sin procesar según la especificación de desinflado en RFC 1951,los productos más notables de Microsoft. Entonces, aunque la codificación de transferencia 'desinflar' usando el formato zlib sería el enfoque más eficiente (y de hecho exactamentepara qué fue diseñado el formato zlib), el uso de 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 de deflación RAW SIN NINGUNA envoltura zlib (o gzip, en realidad), ¿hay algún navegador moderno (por ejemplo, IE6 y superior, FF, Chrome, Safari, etc.) que NO pueda entender el desinflado sin formato datos comprimidos (suponiendo que el encabezado de solicitud HTTP "Aceptar-Codificación" contiene "desinflar")?

Los datos de desinflado SIEMPRE serán unos pocos bytes más pequeños que GZIP.

Si todos estos navegadores pueden decodificar con éxito los datos, ¿cuáles son los inconvenientes de enviar RAW deflate en lugar de zlib?

ACTUALIZACIÓN 11 de septiembre 2010:Se ha creado una plataforma de prueba para esto.aquí