mod_gzip - sirviendo contenido comprimido por el servidor web Apache - Página 8

Autor: Michael Schröpl

Este documento describe algunas posibles mejoras funcionales que, con suerte, podrían implementarse en la versión actual 1.3.26.1a de mod_gzip sin demasiado esfuerzo y mejorar la usabilidad de este módulo.

Clase de registro y valor de la regla de filtro decisiva

La decisión sobre si el contenido de un documento califica para compresión por mod_gzip se toma finalmente durante la evaluación de las reglas de filtro definidas por las directivas mod_gzip_item_include y mod_gzip_item_exclude, que son verificadas por la función mod_gzip_validate1.

Pero esta función se invoca en no menos de cinco posiciones dentro del código fuente, cada vez con diferentes configuraciones de parámetros para partes específicas de las clases de reglas que se deben verificar en ese momento. En algunos de estos casos, está claro a partir de la configuración de parámetros restringida qué clase de regla debe haber llevado al resultado específico (¡pero no qué valor de regla!), en otros casos (como la prueba simultánea de todas las reglas de las clases file, uri, mime y handler) ni siquiera la clase de la regla decisiva está clara (porque mod_gzip_validate1 devuelve un valor de resultado tan inespecífico al llamador que este no puede entender qué ha sucedido exactamente - en algunos casos incluso se codifican errores internos como una decisión debido a una regla de exclusión). En estos casos, ni siquiera es posible una evaluación razonable del código de estado de mod_gzip.

Pero la definición de un conjunto de reglas apropiado es el paso más importante durante el procedimiento completo de configuración de mod_gzip (y actualmente aún bastante complicado). Cualquier información sobre cuál de las reglas definidas decidió en qué casos si el contenido de un documento debía ser comprimido sería útil para el usuario en muchos casos.

Por otro lado, mod_gzip ya admite la transparencia de procesamiento después de manejar con éxito un documento al establecer algunas variables que se pueden usar en los formatos de registro de Apache (el estado de procesamiento, los tamaños de documento antes y después de la compresión, así como el ahorro de volumen en porcentaje - este último erróneamente siempre redondeado hacia arriba). Según esto, mod_gzip podría (justo en el momento en que se tomó la decisión de comprimir el contenido del documento) almacenar fácilmente la clase y el contenido de la regla decisiva en dos variables de registro más que luego se abordarían dentro de un formato de registro a través de los nombres mod_gzip_rule_class y mod_gzip_rule_content.

Nivel de compresión gzip configurable

Actualmente, mod_gzip utiliza el nivel de compresión gzip 6. Esto está codificado de forma rígida por la asignación gz1->level = 6 dentro de la función gz1_init.

Cuanto mayor sea el nivel de compresión (gzip permite valores entre 1 y 9), mejor será el efecto de compresión, pero también mayor será el consumo de tiempo de CPU. Al adaptar este nivel de compresión, un usuario podría resolver el compromiso entre la carga de CPU y el ahorro de ancho de banda de acuerdo con sus propios requisitos. Experimentos propios han demostrado que el nivel 3 ya te acerca al efecto del nivel de compresión 6 - al menos la elección entre estos dos valores debería dejarse al usuario.

Por lo tanto, sería razonable tener este nivel de compresión configurable ofreciendo otra directiva mod_gzip_compression_level.

Una mirada más cercana de Christian Kruse llevó a la conclusión de que el código de compresión de Kevin Kiley para mod_gzip no parece admitir los 9 niveles de compresión para gzip, sino básicamente solo aquellos requeridos para el nivel 6 (aunque la estructura del programa fue diseñada para implementar los 9 niveles más tarde). Por lo tanto, simplemente cambiar la constante mencionada no es suficiente; de hecho, mod_gzip ni siquiera es utilizable después de este tipo de modificación.

Expresiones booleanas en directivas include / exclude

mod_gzip 1.3.19.1a utiliza - causado por su forma de estar incrustado dentro del manejo de solicitudes de Apache - un procedimiento de filtro complejo de dos niveles para decidir si el resultado de una solicitud debe ser comprimido. (En una arquitectura modificada de Apache 2.0, podría ser posible una forma más simple de incrustación.)

Una solicitud actualmente será aceptada por mod_gzip exactamente si durante cada una de las dos fases de decisión al menos una regla include se activa pero ninguna regla exclude. Dado que tales reglas permiten expresiones regulares como valores de parámetro, esto hace que estén disponibles condiciones poderosas.

Sin embargo, todas las reglas son independientes entre sí; las directivas actualmente disponibles no permiten al usuario expresar que tipos MIME distintos solo se entreguen en forma comprimida a navegadores distintos - la conexión Y entre varias reglas falta.

Parece haber solo raras ocasiones en las que esto sería realmente útil - hasta ahora, sería especialmente necesario afinar las reglas de filtro para lidiar con todos los errores de Netscape 4, de otra manera que excluyendo totalmente este navegador de la compresión. Con el tiempo (y la mejor conformidad con los estándares de los navegadores), esta característica puede volverse obsoleta.

Servir encabezados HTTP idénticos para solicitudes GET y HEAD

De acuerdo con el RFC 2616, para una solicitud que utiliza el método HEAD, una implementación compatible con HTTP/1.1 debería servir encabezados HTTP idénticos a los que se habrían servido para una solicitud del mismo recurso utilizando el método GET.

En el caso de mod_gzip, esto significaría que incluso para una solicitud HEAD el contenido tendría que ser comprimido (resp. leído, en caso de un archivo precomprimido estáticamente) solo para poder generar un encabezado HTTP Content-Length correcto.

Hasta ahora, mod_gzip no maneja este (extremadamente raro) caso de aplicación (probablemente debido a consideraciones de rendimiento); sin embargo, de acuerdo con el RFC 2119, esto podría causar que el comportamiento del módulo sea solo condicionalmente compatible con HTTP/1.1 porque debe haber una razón válida para no admitir un requisito recomendado.

Ubicación original de este documento:

http://www.schroepl.net/projekte/mod_gzip/enhancements.htm