htaccess - gzip compression online

¿Servir contenido comprimido directamente? ¿Lo que está mal hacer?

Question

Tengo mi sitio web configurado para servir contenido estático usando compresión gzip, así:

<link rel=''stylesheet'' href=''http://cdn-domain.com/css/style.css.gzip?ver=0.9'' type=''text/css'' media=''all'' />

No veo ningún sitio web haciendo nada similar. Entonces, la pregunta es, ¿qué está mal con esto? ¿Debo esperar deficiencias?

Precisamente, como lo entiendo, la mayoría de los sitios web están configurados para servir archivos estáticos normales (.css, .js, etc.) y contenido comprimido (.css.gz, .js.gz, etc.) solo si la solicitud incluye un Accept-Encoding: gzip encabezado Accept-Encoding: gzip . ¿Por qué deberían hacer esto cuando todos los navegadores admiten gzip la misma manera?

PD: No veo ningún problema de rendimiento porque todo el contenido estático está comprimido en formato comprimido antes de subirlo a la CDN, que simplemente sirve los archivos comprimidos. Por lo tanto, no hay estrés / tensión en mi servidor.

En caso de que sea útil, aquí está la información del encabezado de respuesta HTTP para el archivo CSS comprimido:

Y esto para gzipped archivo favicon.ico:

Answer 1

Compatibilidad Content-Encoding: gzip no es un requisito de ninguna especificación HTTP actual, es por eso que hay un disparador en la forma del encabezado de la solicitud.

¿En la práctica? Si su audiencia está usando un navegador web y solo le preocupan los usuarios legítimos, entonces hay muy pocas posibilidades de que alguien realmente se vea afectado por el hecho de que solo haya versiones gzip preprocesadas disponibles. Es un remanente de una época pasada. Los navegadores en estos días deben manejar el contenido comprimido con gif, incluso si no lo solicitan, siempre y cuando también les proporcione los encabezados correctos para el contenido que se les entrega. Es importante darse cuenta de que la solicitud / respuesta HTTP es una conversación y que la mayoría de los encabezados de una solicitud son solo eso; una petición En su mayor parte, el servidor en el otro extremo no tiene la obligación de respetar ningún encabezado en particular, y siempre que devuelvan una respuesta válida que tenga sentido, el cliente en el otro extremo debe hacer todo lo posible para dar sentido a lo que se devolvió. . Esto incluye habilitar gzip si el servidor responde que lo ha usado.

Sin embargo, si su objetivo es el consumo de máquinas, tenga cuidado. La gente todavía piensa que es una buena idea escribir sus propios analizadores HTTP / SMTP / etc, a pesar de que el tema se ha acabado en varias bibliotecas para casi todos los idiomas. Todas las bibliotecas deberían admitir gzip simplemente bien, pero los analizadores enrollados a mano generalmente no lo hacen.