mod_gzip - sirviendo contenido comprimido por el servidor web Apache

Autor: Michael Schröpl

Realmente realizar la instalación no es difícil, pero encontrar el método que mejor se adapte a las necesidades de tu instalación de Apache puede llevar algo de tiempo.

Por lo tanto, se recomienda encarecidamente que leas este capítulo completamente y te familiarices con los pros y los contras de las diferentes opciones antes de seleccionar el método de operación y realizar la instalación.

El documento en cuestión cubre especialmente el modelo de procesamiento interno de mod_gzip como un módulo de Apache y puede proporcionar información que puede ser útil para entender el método de evaluación de mod_gzip para las directivas de configuración.

Fundamentos

Introducción

El servidor web Apache admite dos métodos diferentes de integrar un módulo en su código de programa:

integración estática y
integración dinámica.

Dependiendo del concepto de operación utilizado para tu servidor Apache y los requisitos dados

uno de estos dos métodos de operación para mod_gzip debe ser seleccionado y
el conjunto de archivos requerido para este método debe ser descargado.

Integración estática de un módulo de Apache

La integración estática significa que el módulo se convierte en una parte permanente del binario de programa enlazado httpd que implementa el servidor Apache.

Para esto, el código fuente del servidor Apache debe ser

ampliado con el código fuente de este módulo y luego
compilado en su totalidad utilizando un compilador de C.

Normalmente, cada administrador puede querer usar un conjunto diferente de características para su servidor Apache adaptado a sus propios requisitos; por lo tanto, no parece factible proporcionar archivos de programa listos para ejecutar en una multitud de plataformas para su descarga.

Integración dinámica de un módulo de Apache

La integración dinámica significa que el módulo puede ser cargado desde un archivo de módulo separado como objeto compartido al iniciar el proceso de Apache.

Para esto

el archivo de objeto compartido de este módulo para la plataforma de destino requerida debe ser - ya sea adquirido o generado y
instalado en el directorio correspondiente de Apache y
el archivo de configuración de Apache debe ser ampliado con una directiva para cargar este módulo.

La estructura del código fuente del módulo mod_gzip

La mayoría de los módulos de Apache consisten en un solo archivo de código fuente. Este archivo puede ser compilado invocando el programa apxs (con los valores de parámetros correspondientes); para la instalación del objeto compartido creado de esta manera se requeriría una invocación más de apxs (con diferentes valores de parámetros).

Desde la versión 1.3.26.1a, el código fuente de mod_gzip se divide en tres archivos separados:

mod_gzip.c (alrededor de 8000 líneas) contiene todas las funciones que son necesarias para implementar la lógica de procesamiento del módulo de Apache mod_gzip.
Este archivo depende mucho de la interfaz del módulo de la versión 1.3 de Apache (que no cambió durante muchos años).
mod_gzip_debug.c (alrededor de 500 líneas) contiene funciones que son necesarias únicamente para tareas de depuración para el desarrollador; parte de estas funciones ni siquiera están contenidas en un mod_gzip compilado ‘de la manera normal’ (dependiendo de los valores de las directivas del compilador de tipo -D para definir constantes simbólicas).
mod_gzip_compress.c (alrededor de 3000 líneas) contiene la implementación de la función de compresión gzip de Kevin Kiley, la que ‘realmente hace el trabajo’.
Esta parte no depende de ninguna versión específica de Apache y (desde un punto de vista puramente técnico) podría ser utilizada por otras herramientas de compresión también (como mod_deflate que actualmente utiliza ‘zlib’ para compresión).

Esta estructura del código fuente hace que el mantenimiento de mod_gzip sea un poco más fácil - y la instalación un poco más complicada (ya que ahora varios archivos fuente deben ser compilados en lugar de solo uno). Por lo tanto, mod_gzip ahora proporciona Makefile s para simplificar este proceso de instalación.

Descarga

Dependiendo de cuál de los conceptos de operación mencionados anteriormente se va a ejecutar, se deben utilizar diferentes archivos (adecuados para el respectivo propósito de uso).

A partir de este escrito, los siguientes archivos están disponibles para cada versión de mod_gzip en la página de descarga del proyecto mod_gzip:

| mod_gzip- versión .tgz: | un archivo tar comprimido con gzip del producto mod_gzip, que incluye - el código fuente del módulo (en el lenguaje de programación C),

varios Makefile s (para compilar el código fuente),
un Change-Log (como documentación breve de los cambios más importantes para todas las versiones del programa) y
la documentación en cuestión. | | ApacheModuleGzip.dll.zip: | un archivo ZIP que contiene el archivo de objeto compartido de mod_gzip para la plataforma Windows. | | mod_gzip- versión -FreeBSD-4.6-i386.so.gz: | un archivo comprimido con gzip que contiene el archivo de objeto compartido de mod_gzip para la plataforma FreeBSD-UNIX 4.6. | | mod_gzip.so.gz: | un archivo comprimido con gzip que contiene el archivo de objeto compartido de mod_gzip para la plataforma Solaris 2.7. |

Si mod_gzip se va a ejecutar con integración dinámica en alguna otra plataforma, entonces el archivo de módulo compartido para esta plataforma debe ser creado por el administrador.

Integración estática de mod_gzip

La compilación normal del servidor web Apache

El procedimiento para instalar el servidor web Apache en una máquina UNIX documentado por el Grupo Apache es el siguiente (en la versión corta):

descargar el archivo con el código fuente de Apache desde la WWW
descomprimir el archivo
navegar al directorio creado por la operación anterior
leer y entender el archivo INSTALL
iniciar el script de shell ./configure con los valores de parámetros apropiados (esto causará la creación de archivos Makefile en un gran número de subdirectorios)
make install (esto causará la compilación e instalación del servidor Apache, incluida su documentación en línea)

Si el servidor web Apache ha sido creado de esta manera, entonces los módulos enviados normalmente se convierten en partes estáticas del archivo de programa creado httpd en el directorio del programa Apache - a menos que hayas especificado algo diferente en los parámetros de la llamada a configure.

(La llamada real a configure puede volverse muy extensa, dependiendo del grado de desviación de los valores de parámetros estándar. Recomiendo almacenar esta llamada en un pequeño script de shell para documentar el tipo de instalación procesada, por cierto.)

La integración de mod_gzip en el código fuente de Apache

El código fuente de los módulos oficiales de Apache se encuentra en el subdirectorio src/modules del archivo tar descomprimido del software de Apache.

Para que mod_gzip sea tratado como un módulo estándar de Apache por este mecanismo, son necesarias las siguientes preparaciones:

Descomprimir y descomponer el contenido del archivo de descarga que contiene el código fuente de mod_gzip (lo que creará un directorio mod_gzip- número de versión),
Crear un directorio src/modules/gzip dentro del árbol de directorios del código fuente de Apache
Copiar todos los archivos con las extensiones .c*, .h y .tmpl en este nuevo directorio gzip.

Como siguiente paso, amplías la llamada a configure con el parámetro –activate-module=src/modules/gzip/mod_gzip.c. Ahora el script configure encontrará el código fuente de mod_gzip y creará un Makefile adecuado a partir del archivo enviado Makefile.tmpl - registrado por los mensajes

 + módulo gzip activado (modules/gzip/mod_gzip.c)

Creando Makefile en src/modules/gzip

el último igual que para los propios módulos de Apache. (El Makefile enviado con mod_gzip no es adecuado para este tipo de instalación - este es solo para la creación de un archivo de objeto compartido.)

Ahora la instalación de Apache funcionará como de costumbre - y mod_gzip será tratado como un módulo normal de Apache.

Pero configure sabe que un módulo integrado a través del parámetro –activate-module es un módulo de terceros que probablemente tenga requisitos específicos, y por lo tanto cargará mod_gzip automáticamente en la parte superior de la pila de módulos para que tenga acceso a la solicitud HTTP entrante antes que todos los demás módulos - que es exactamente lo que mod_gzip necesita urgentemente.

En algunas plataformas, el configure de Apache no parece establecer automáticamente el valor de la variable de entorno $(LIBEXT) al valor adecuado de .a. En este caso, la compilación de mod_gzip fallará. La razón exacta de este comportamiento es desconocida hasta ahora; como solución alternativa, puedes reemplazar la línea

LIB=libgzip.$(LIBEXT)

por

LIB=libgzip.a

dentro del archivo enviado Makefile.tmpl, es decir, insertar el valor adecuado manualmente.

¡Asegúrate de usar un editor que no expanda los caracteres de tabulación a espacios en blanco para esta tarea!

(Para probar: ¿Qué sucede al integrar más de un módulo de terceros con –activate-module? ¿Es relevante el orden de los valores de parámetros en este caso?)

Verificar que mod_gzip se ha integrado correctamente

Para comprobar si mod_gzip realmente se ha integrado en el código del programa Apache como se solicitó, el servidor Apache proporciona el comando httpd -l. Esto mostrará una lista de todos los módulos integrados (en el orden en que serán cargados); mod_gzip.c debería ser la última entrada mostrada allí.

Integración dinámica de mod_gzip

El concepto de módulos de Apache cargables

El servidor web Apache admite el concepto de módulos cargables.

Casi cada módulo de Apache puede ser

compilado como un objeto compartido y luego
cargado dinámicamente en el espacio de direcciones de Apache al inicio del servidor Apache (mediante el uso de las directivas de configuración correspondientes).

El manejo de módulos cargables requiere conocimientos adicionales sobre la configuración de Apache (porque el orden en que se cargan estos módulos puede ser significativo para su funcionamiento) pero permite cambios en el rango de código del servidor Apache sin tener que recompilar su código fuente.

En plataformas como Windows (donde no muchos administradores de Apache tienen un entorno de desarrollo C a mano para compilar y vincular el código de Apache) el uso de módulos cargables puede ser a menudo la única posibilidad de ampliar el alcance funcional del servidor Apache.

La documentación de Apache 1.3 proporciona los siguientes artículos sobre este tema:

Soporte de Objetos Compartidos Dinámicos (DSO) - la descripción del concepto correspondiente para el servidor web Apache
Módulo mod_so - la descripción del módulo de Apache para cargar otros módulos y las directivas de configuración requeridas

Directiva para cargar mod_gzip

Para agregar dinámicamente el objeto compartido de mod_gzip al código de Apache, se requiere una de las siguientes directivas de configuración:

# ---------------------------------------------------------------------  
# cargar un DLL / Windows:  
  LoadModule gzip_module modules/ApacheModuleGzip.dll  
# ---------------------------------------------------------------------  
# cargar un DSO / UNIX:  
  LoadModule gzip_module modules/mod_gzip.so**  
# ---------------------------------------------------------------------  
# (ninguno de los dos si el módulo está integrado estáticamente)  
# ---------------------------------------------------------------------

El nombre de archivo real puede ser seleccionado libremente - solo tiene que coincidir con el nombre del archivo que se utiliza efectivamente. Por otro lado, este nombre puede depender de la plataforma del sistema operativo e incluso del método de compilación utilizado para este módulo - en este caso, o bien la directiva mostrada arriba debe ser adaptada o el archivo debe ser renombrado en consecuencia.

El manejo de módulos por Apache 1.3

El servidor Apache puede cargar dinámicamente cualquier número de módulos. Al hacerlo, las directivas LoadModule correspondientes se procesan en el orden de su ocurrencia dentro del archivo de configuración.

Pero los módulos se cargan en una pila dentro de la memoria de trabajo: El módulo que se ha cargado último será el primero en obtener acceso al manejo de la correspondiente solicitud HTTP al servidor web Apache - y puede entonces decidir si considerarse responsable de manejar esta solicitud o no.

Solo uno de todos los módulos en cuestión puede ser responsable de manejar una solicitud en Apache 1.3 - los módulos posteriores ni siquiera serán preguntados.

La integración de mod_gzip en la evaluación de una solicitud de Apache

Por lo tanto, para poder procesar la salida de módulos arbitrarios, mod_gzip tiene que hacer algo que en realidad contradice la arquitectura de Apache 1.3: Tiene que ‘manejar’ una solicitud pero posteriormente revocar la responsabilidad de manejar esta solicitud. Solo mediante este procedimiento el módulo que es efectivamente responsable de manejar la solicitud puede ser activado por el servidor Apache en absoluto.

En esta primera fase, el ‘manejo’ de esta solicitud por mod_gzip no significa comprimir el contenido de la página que se va a servir - porque este contenido ni siquiera existe aún, ¡todavía tiene que ser generado por otro módulo! En su lugar, en este momento mod_gzip solo se prepara para ser preguntado nuevamente si quiere hacer algo después de la creación del contenido de la página. Solo en esta segunda fase de su activación (donde el contenido de la respuesta HTTP ya está disponible) mod_gzip puede realizar su tarea esencial, que es comprimir el contenido de un paquete de respuesta HTTP (y la modificación de ciertos encabezados HTTP).

Este ‘registro’ para el posterior procesamiento de la respuesta HTTP realizado por mod_gzip es necesario solo si mod_gzip no puede determinar ya en esta etapa que definitivamente no estará interesado en procesar el contenido de la respuesta de todos modos.

Así, en esta primera fase, mod_gzip ya realiza una parte de la evaluación de las directivas de filtro especificadas en la configuración de Apache: Verifica aquellas reglas donde puede hacerlo basándose únicamente en la descripción de la solicitud (es decir, el contenido de los encabezados HTTP correspondientes). Esto se aplica a las reglas de mod_gzip_item_include / mod_gzip_item_exclude del tipo

reqheader (contenido de los encabezados de solicitud HTTP de la solicitud),
url (URL del recurso HTTP solicitado),
file (nombre del archivo afectado por esta solicitud, después de la evaluación de todas las traducciones de Alias etc.) y
handler (nombre del controlador responsable de evaluar esta solicitud, de acuerdo con la configuración de Apache).

Si la evaluación de estas reglas de filtro ya demuestra que el resultado de esta solicitud no debe ser comprimido, es decir, si

al menos una regla exclude se satisface o
ninguna de las reglas include se satisface o
si cualquier otra condición para realizar la compresión no se satisface (por ejemplo, en esta etapa ya se puede verificar si el cliente ha autorizado la entrega de datos comprimidos al enviar el encabezado HTTP Accept-Encoding: gzip)

entonces no es necesario que mod_gzip verifique las reglas restantes después de la creación del contenido de la respuesta - así que esto no sucederá, porque mod_gzip recuerda el resultado de la primera fase de evaluación para cada solicitud y termina la segunda fase inmediatamente en este caso.

De lo contrario, en la segunda fase de su operación, mod_gzip verifica las reglas de filtro restantes que solo pueden ser evaluadas en función del contenido real del paquete de respuesta generado:

rspheader (contenido de los encabezados de respuesta HTTP) así como
mime (tipo de contenido HTTP del resultado).

Además, ahora se prueban algunas otras condiciones, como el tamaño del paquete de respuesta (directivas mod_gzip_minimum_file_size rsp. mod_gzip_maximum_file_size).

Y solo si todas estas pruebas dieron como resultado un resultado positivo, se realizará realmente la compresión del paquete de respuesta.

La posición de mod_gzip dentro de la secuencia de carga de todos los módulos de Apache

Para poder realizar todas las tareas descritas anteriormente, el módulo mod_gzip debe tener acceso al manejo de la solicitud HTTP antes de cada otro módulo de Apache cuya salida se supone que debe manejar. Debido al orden invertido de acceso al manejo de una solicitud para todos los módulos de Apache, mod_gzip debería ser cargado como el último de todos los módulos de Apache.

Para la integración estática, este orden de módulos está definido por el ‘plano’ del programa httpd durante la compilación del código fuente de Apache. El procedimiento para compilar el código fuente de Apache enviado por el Grupo Apache, activado por el script de shell configure, conoce todas las dependencias entre los módulos enviados (y asegura un orden correspondiente de estos módulos) pero no los requisitos de módulos de terceros como mod_gzip que se integran en el proceso de compilación mediante el parámetro configure –add-module= archivo. Para permitir un máximo de influencia a estos módulos de terceros, tales módulos se cargan como últimos módulos en la pila de módulos.

Así que si mod_gzip se va a integrar en un servidor Apache como el único módulo de terceros, entonces configure automáticamente hace lo correcto. En caso de usar más de un módulo de terceros, el administrador es responsable de ordenar estos módulos (¿quizás por el orden de sus valores –add-module=? No he probado esto aún).

Compilando mod_gzip usando apxs

La función de la utilidad de compilación de Apache apxs

Si un servidor Apache se opera para soportar la integración dinámica de módulos (es decir, utiliza el módulo mod_so), entonces un programa utilitario llamado apxs se generará en el directorio bin de Apache durante la instalación de Apache.

Este programa permite a su usuario compilar el código fuente de un módulo de Apache (utilizando un compilador de C) y crear un archivo objeto compartido correspondiente sin requerir que el código fuente completo de los servidores Apache esté disponible: apxs conoce todas las interfaces de programa de Apache requeridas y suministra al compilador de C la información necesaria.

Creando un objeto compartido para mod_gzip usando make

Para ahorrar al usuario de averiguar cómo exactamente mod_gzip debe ser compilado e instalado completamente al usar apxs, se proporciona un archivo llamado Makefile dentro del archivo de código fuente.

Usar este Makefile reduce el procedimiento de instalación a los siguientes pasos:

Extraer los archivos del archivo de código fuente de mod_gzip descargado en un directorio (nuevo, temporal) de tu elección y cambiar tu posición de directorio actual a allí.
Averiguar el nombre de ruta del programa apxs de tu instalación de Apache.
Realizar la compilación ejecutando el comando make APXS=*tu_ruta_apxs* Esto creará el archivo objeto compartido mod_gzip.so dentro del directorio actual.
(Este paso de la secuencia de operación puede omitirse ya que luego será cubierto por el paso siguiente.)
Realizar la instalación ejecutando el comando make install APXS=*tu_ruta_apxs* Esto no solo copiará el archivo objeto compartido en el directorio correspondiente de la instalación de Apache, sino que también ampliará automáticamente el archivo de configuración de Apache httpd.conf con las directivas requeridas LoadModule y AddModule también … si no te gusta que programas externos reescriban tus valiosos archivos de configuración, podrías preferir realizar este paso final manualmente, o al menos hacer una copia de seguridad de tu configuración de Apache primero.

Además de estos pasos necesarios, el Makefile admite los siguientes comandos (que pueden ser más de interés para los desarrolladores):

make clean elimina todos los archivos de módulo objeto creados de los archivos de código fuente de mod_gzip del directorio actual (es decir, todos los archivos con el patrón de nombre *.o).
make clean adicionalmente elimina el archivo objeto compartido creado mod_gzip.so también.

Ubicación original de este documento:

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

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