optimization - chequear - gzip descargar
Desinflar la compatibilidad y las ventajas del navegador de compresión con respecto a GZIP (4)
ACTUALIZACIÓN 10 de febrero de 2012:
zOompf ha completado una investigación muy exhaustiva sobre este tema here . Triunfará cualquier hallazgo a continuación.
ACTUALIZACIÓN 11 de septiembre de 2010:
Se ha creado una plataforma de prueba para esto here
Definiciones HTTP 1.1 de GZIP y DEFLATE (zlib) para obtener información de contexto:
"''Gzip'' es el formato gzip, y ''deflate'' es el formato zlib . Probablemente deberían haber llamado al segundo ''zlib'' para evitar confusiones con el formato de datos comprimidos sin formato. Mientras que el HTTP 1.1 RFC 2616 señala correctamente 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 del desinflado en RFC 1951, especialmente los productos Microsoft . Así que aunque el ''desinflado'' la codificación de transferencia usando el formato zlib sería el enfoque más eficiente ( y de hecho exactamente para lo que se diseñó 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 HTTP 1.1 autores ". (fuente: http://www.gzip.org/zlib/zlib_faq.html )
Entonces, mi pregunta: si envío datos de desinflado RAW SIN envoltorio zlib (o gzip, para el caso) hay navegadores modernos (por ejemplo, IE6 y superior, FF, Chrome, Safari, etc.) que NO pueden entender el desinflado sin procesar datos comprimidos (suponiendo que el encabezado de solicitud HTTP "Aceptar-Codificación" contiene "desinflar")?
Los datos de deflación SIEMPRE serán unos pocos bytes más pequeños que GZIP.
Si todos estos navegadores pueden decodificar con éxito los datos, ¿qué inconvenientes hay para enviar desinflado RAW en lugar de zlib?
ACTUALIZACIÓN 11 de septiembre de 2010:
Se ha creado una plataforma de prueba para esto here
ACTUALIZACIÓN: los navegadores han estado retirando soporte para desinflar sin formato. zOompf ha completado una investigación muy exhaustiva sobre este tema here . Desafortunadamente, parece que el desinflado en crudo NO es seguro de usar.
Visite http://www.vervestudios.co/projects/compression-tests/results para obtener más resultados.
Aquí están los navegadores que han sido probados:
/* 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
* Android envía el encabezado de solicitud HTTP "Aceptar codificación: gzip". Desinflar no está permitido.
Concluyo que siempre podemos enviar DEFLATE sin procesar (cuando el encabezado de solicitud HTTP "Aceptar codificación" contiene "desinflar") y el navegador podrá interpretar correctamente los datos codificados. ¿Alguien puede probar esto mal?
Nota: La implementación nativa de .NET de DEFLATE (System.IO.Compression.DeflateStream) es raw DEFLATE. También apesta. Utilice zlib.net para todas sus necesidades de desinflado de .NET.
¿No es el caso que AddOutputFilterByType DEFLATE usando mod_deflate envía por gzip de forma predeterminada?
El navegador Android 1.6 (v4) falla tanto la prueba zlib como la prueba de desinflado en su página. Lo he agregado a tu lista.
por lo que yo sé, sí, casi siempre "siempre puedes enviar DEFLATE sin procesar y todo estaría bien" ... no hay "siempre", sino la mayoría de los casos. si no, este es el problema del navegador.