mod_gzip - servire contenuti compressi dal server web Apache

Autore: Michael Schröpl

Effettivamente eseguire l’installazione non è difficile, ma trovare il metodo che meglio si adatta alle esigenze della tua installazione Apache potrebbe richiedere del tempo.

Pertanto, si raccomanda vivamente di leggere questo capitolo completamente e di prendere coscienza dei pro e dei contro delle diverse opzioni prima di selezionare il metodo operativo e di eseguire l’installazione.

Il documento in questione tratta in particolare del modello di elaborazione interno di mod_gzip come modulo Apache e può quindi fornire informazioni che possono essere utili per comprendere il metodo di valutazione di mod_gzip per le direttive di configurazione.

Fondamenti

Introduzione

Il server web Apache supporta due diversi metodi di integrazione di un modulo nel suo codice sorgente:

integrazione statica e
integrazione dinamica.

A seconda del concetto operativo utilizzato per il tuo server Apache e dei requisiti forniti

uno di questi due metodi operativi per mod_gzip deve essere selezionato e
il set di file richiesto per questo metodo deve essere scaricato.

Integrazione statica di un modulo Apache

L’integrazione statica significa che il modulo diventa una parte permanente del file binario del programma httpd che implementa il server Apache.

Per questo, il codice sorgente del server Apache deve essere

esteso dal codice sorgente di questo modulo e poi
compilato nel suo insieme utilizzando un compilatore C.

Normalmente ogni amministratore potrebbe voler utilizzare un diverso set di funzionalità per il proprio server Apache adattato alle proprie esigenze; pertanto non sembra fattibile fornire file di programma pronti per l’uso su una moltitudine di piattaforme per il download.

Integrazione dinamica di un modulo Apache

L’integrazione dinamica significa che il modulo può essere caricato da un file di modulo separato come oggetto condiviso all’avvio del processo Apache.

Per questo

il file oggetto condiviso di questo modulo per la piattaforma target richiesta deve essere - o procurato o generato e
installato nella corrispondente directory di Apache e
il file di configurazione di Apache deve essere esteso da una direttiva per caricare questo modulo.

La struttura del codice sorgente del modulo mod_gzip

La maggior parte dei moduli Apache consiste in un solo file di codice sorgente. Questo file può essere compilato invocando il programma apxs (con i valori dei parametri corrispondenti); per l’installazione dell’oggetto condiviso creato in questo modo sarebbe necessaria un’altra invocazione di apxs (con valori di parametri diversi).

A partire dalla versione 1.3.26.1a, il codice sorgente di mod_gzip è suddiviso in tre file separati:

mod_gzip.c (circa 8000 righe) contiene tutte le funzioni necessarie per implementare la logica di elaborazione del modulo Apache mod_gzip.
Questo file dipende molto dall’interfaccia del modulo della versione Apache 1.3 (che non è cambiata per molti anni).
mod_gzip_debug.c (circa 500 righe) contiene funzioni che sono necessarie solo per compiti di debug per lo sviluppatore; parte di queste funzioni non è nemmeno contenuta in un mod_gzip compilato ‘nel modo normale’ (a seconda dei valori delle direttive del compilatore fornite di tipo -D per definire costanti simboliche).
mod_gzip_compress.c (circa 3000 righe) contiene l’implementazione della funzione di compressione gzip di Kevin Kiley, quella che ‘fa effettivamente il lavoro’.
Questa parte non dipende da alcuna versione specifica di Apache e (da un punto di vista puramente tecnico) potrebbe essere utilizzata anche da altri strumenti di compressione (come mod_deflate che attualmente utilizza ‘zlib’ per la compressione).

Questa struttura del codice sorgente rende la manutenzione di mod_gzip un po’ più semplice - e l’installazione un po’ più complicata (poiché ora devono essere compilati diversi file sorgente invece di uno solo). Pertanto, mod_gzip ora fornisce Makefile per semplificare questo processo di installazione.

Download

A seconda di quale dei concetti operativi sopra menzionati deve essere eseguito, devono essere utilizzati file diversi (adatti allo scopo rispettivo).

A partire da questo scritto, i seguenti file sono disponibili per ciascuna versione di mod_gzip nella pagina di download del progetto mod_gzip:

| mod_gzip- versione .tgz: | un archivio tar compresso con gzip del prodotto mod_gzip, inclusi - il codice sorgente del modulo (nel linguaggio di programmazione C),

diversi Makefile (per compilare il codice sorgente),
un Change-Log (come documentazione breve delle modifiche più importanti per tutte le versioni del programma) e
la documentazione in questione. | | ApacheModuleGzip.dll.zip: | un archivio ZIP contenente il file oggetto condiviso di mod_gzip per la piattaforma Windows. | | mod_gzip- versione -FreeBSD-4.6-i386.so.gz: | un file compresso con gzip contenente il file oggetto condiviso di mod_gzip per la piattaforma FreeBSD-UNIX 4.6. | | mod_gzip.so.gz: | un file compresso con gzip contenente il file oggetto condiviso di mod_gzip per la piattaforma Solaris 2.7. |

Se mod_gzip deve essere eseguito con integrazione dinamica su un’altra piattaforma, allora il file del modulo condiviso per questa piattaforma deve essere creato dall’amministratore.

Integrazione statica di mod_gzip

La normale compilazione del server web Apache

La procedura per installare il server web Apache su una macchina UNIX documentata dal Gruppo Apache è la seguente (nella versione breve):

scarica l’archivio con il codice sorgente di Apache dal WWW
estrai l’archivio
naviga nella directory creata dall’operazione precedente
leggi e comprendi il file INSTALL
avvia lo script shell ./configure con i valori di parametro appropriati (questo causerà la creazione di file Makefile in un gran numero di sottodirectory)
make install (questo causerà la compilazione e l’installazione del server Apache, inclusa la sua documentazione online)

Se il server web Apache è stato creato in questo modo, i moduli forniti diventano normalmente parti statiche del file di programma creato httpd nella directory del programma Apache - a meno che tu non abbia specificato qualcosa di diverso nei parametri della chiamata a configure.

(La chiamata effettiva a configure può diventare molto estesa, a seconda del grado di deviazione dai valori di parametro standard. Raccomando di memorizzare questa chiamata stessa in un piccolo script shell per documentare il tipo di installazione elaborata nel frattempo.)

L’integrazione di mod_gzip nel codice sorgente di Apache

Il codice sorgente dei moduli ufficiali di Apache è contenuto nella sottodirectory src/modules dell’archivio tar estratto del software Apache.

Per far sì che mod_gzip venga trattato come un modulo Apache standard da questo meccanismo, sono necessarie le seguenti preparazioni:

Decomprimere e estrarre il contenuto dell’archivio di download contenente il codice sorgente di mod_gzip (che creerà una directory mod_gzip- numero di versione),
Creare una directory src/modules/gzip all’interno dell’albero delle directory del codice sorgente di Apache
Copiare tutti i file con le estensioni .c*, .h e .tmpl in questa nuova directory gzip.

Come passo successivo, estendi la chiamata a configure con il parametro –activate-module=src/modules/gzip/mod_gzip.c. Ora lo script configure troverà il codice sorgente di mod_gzip e creerà un Makefile adatto dal file fornito Makefile.tmpl - registrato dai messaggi

 + modulo gzip attivato (modules/gzip/mod_gzip.c)

Creazione di Makefile in src/modules/gzip

quest’ultimo come per i moduli di Apache stessi. (Il Makefile fornito con mod_gzip non è adatto per questo tipo di installazione - questo è solo per la creazione di un file oggetto condiviso.)

Ora l’installazione di Apache funzionerà come al solito - e mod_gzip sarà trattato come un normale modulo Apache.

Ma configure sa che un modulo integrato tramite il parametro –activate-module è un modulo di terze parti che potrebbe avere requisiti specifici, e quindi caricherà mod_gzip automaticamente in cima allo stack dei moduli in modo che avrà accesso alla richiesta HTTP in arrivo prima di tutti gli altri moduli - il che è esattamente ciò di cui mod_gzip ha urgentemente bisogno.

Su alcune piattaforme, la configurazione di Apache non sembra impostare automaticamente il valore della variabile di ambiente $(LIBEXT) al valore corretto di .a. In questo caso, la compilazione di mod_gzip fallirà. Il motivo esatto di questo comportamento non è noto al momento; come soluzione alternativa, puoi sostituire la riga

LIB=libgzip.$(LIBEXT)

con

LIB=libgzip.a

all’interno del file fornito Makefile.tmpl, cioè inserire manualmente il valore corretto.

Assicurati di utilizzare un editor che non espande i caratteri di tabulazione in spazi bianchi per questo compito!

(Da testare: Cosa succede quando si integrano più di un modulo di terze parti con –activate-module? L’ordine dei valori dei parametri è rilevante in questo caso?)

Verifica che mod_gzip sia stato integrato correttamente

Per controllare se mod_gzip è stato effettivamente integrato nel codice sorgente di Apache come richiesto, il server Apache fornisce il comando httpd -l. Questo mostrerà un elenco di tutti i moduli integrati (nell’ordine in cui verranno caricati); mod_gzip.c dovrebbe essere l’ultimo elemento visualizzato lì.

Integrazione dinamica di mod_gzip

Il concetto di moduli Apache caricabili

Il server web Apache supporta il concetto di moduli caricabili.

Quasi ogni modulo Apache può essere

compilato come oggetto condiviso e poi
caricato dinamicamente nello spazio indirizzi di Apache all’avvio del server Apache (utilizzando le corrispondenti direttive di configurazione).

La gestione dei moduli caricabili richiede conoscenze aggiuntive sulla configurazione di Apache (poiché l’ordine in cui questi moduli vengono caricati può essere significativo per il loro funzionamento) ma consente modifiche all’intervallo di codice del server Apache senza dover ricompilare il suo codice sorgente.

Su piattaforme come Windows (dove non molti amministratori Apache hanno un ambiente di sviluppo C a disposizione per compilare e collegare il codice Apache) l’uso di moduli caricabili può spesso essere l’unica possibilità per ampliare l’ambito funzionale del server Apache.

La documentazione di Apache 1.3 fornisce i seguenti articoli su questo argomento:

Supporto per oggetti condivisi dinamici (DSO) - la descrizione del concetto corrispondente per il server web Apache
Modulo mod_so - la descrizione del modulo Apache per il caricamento di altri moduli e le direttive di configurazione richieste

Direttiva per caricare mod_gzip

Per aggiungere dinamicamente l’oggetto condiviso mod_gzip al codice di Apache, è necessaria una delle seguenti direttive di configurazione:

# ---------------------------------------------------------------------  
# carica un DLL / Windows:  
  LoadModule gzip_module modules/ApacheModuleGzip.dll  
# ---------------------------------------------------------------------  
# carica un DSO / UNIX:  
  LoadModule gzip_module modules/mod_gzip.so**  
# ---------------------------------------------------------------------  
# (nessuno dei due se il modulo è integrato staticamente)  
# ---------------------------------------------------------------------

Il nome del file effettivo può essere selezionato liberamente - deve solo corrispondere al nome del file effettivamente utilizzato. D’altra parte, questo nome può dipendere dalla piattaforma del sistema operativo e persino dal metodo di compilazione utilizzato per questo modulo - in questo caso o la direttiva mostrata sopra deve essere adattata o il file deve essere rinominato di conseguenza.

La gestione dei moduli da parte di Apache 1.3

Il server Apache può caricare dinamicamente un numero qualsiasi di moduli. Durante questo processo, le corrispondenti direttive LoadModule vengono elaborate nell’ordine della loro occorrenza all’interno del file di configurazione.

Ma i moduli vengono caricati su uno stack all’interno della memoria di lavoro: Il modulo che è stato caricato ultimo sarà il primo ad avere accesso alla gestione della corrispondente richiesta HTTP al server web Apache - e può quindi decidere se considerarsi responsabile della gestione di questa richiesta o meno.

Solo uno di tutti i moduli in questione può essere responsabile della gestione di una richiesta in Apache 1.3 - i moduli successivi non verranno nemmeno interrogati.

L’integrazione di mod_gzip nella valutazione di una richiesta da parte di Apache

Pertanto, per poter elaborare l’output di moduli arbitrari, mod_gzip deve fare qualcosa che in realtà contraddice l’architettura di Apache 1.3: Deve ‘gestire’ una richiesta ma successivamente revocare la responsabilità per gestire questa richiesta. Solo attraverso questa procedura il modulo che è effettivamente responsabile della gestione della richiesta può ancora essere attivato dal server Apache.

In questa prima fase la ‘gestione’ di questa richiesta da parte di mod_gzip non significa non comprimere il contenuto della pagina da servire - perché questo contenuto non esiste nemmeno ancora, deve ancora essere generato da un altro modulo! Invece, a questo punto, mod_gzip si prepara solo a essere interrogato di nuovo se desidera fare qualcosa dopo la creazione del contenuto della pagina. Solo in questa seconda fase della sua attivazione (dove il contenuto della risposta HTTP è già disponibile) mod_gzip può eseguire il suo compito essenziale, che è comprimere il contenuto di un pacchetto di risposta HTTP (e la modifica di alcuni intestazioni HTTP).

Questa ‘registrazione’ per la successiva post-elaborazione della risposta HTTP eseguita da mod_gzip è necessaria solo se mod_gzip non può già determinare in questa fase che non sarà comunque interessato a elaborare il contenuto della risposta.

Pertanto, in questa prima fase, mod_gzip esegue già parte della valutazione delle direttive di filtro specificate nella configurazione di Apache: Controlla quelle regole dove può farlo basandosi solo sulla descrizione della richiesta (cioè il contenuto delle corrispondenti intestazioni HTTP). Questo si applica alle regole mod_gzip_item_include / mod_gzip_item_exclude del tipo

reqheader (contenuto delle intestazioni della richiesta HTTP della richiesta),
url (URL della risorsa HTTP richiesta),
file (nome del file del file interessato da questa richiesta, dopo la valutazione di tutte le traduzioni Alias ecc.) e
handler (nome del gestore responsabile della valutazione di questa richiesta, secondo la configurazione di Apache).

Se la valutazione di queste regole di filtro dimostra già che il risultato di questa richiesta non deve essere compresso, cioè se

almeno una regola exclude è soddisfatta o
nessuna delle regole include è soddisfatta o
se qualsiasi altra condizione per eseguire la compressione non è soddisfatta (ad esempio, a questo punto può già essere verificato se il client ha autorizzato il servizio di dati compressi inviando l’intestazione HTTP Accept-Encoding: gzip)

allora non è necessario che mod_gzip controlli le regole rimanenti dopo la creazione del contenuto della risposta - quindi non accadrà, perché mod_gzip ricorda il risultato della prima fase di valutazione per ciascuna richiesta e termina immediatamente la seconda fase in questo caso.

Altrimenti, nella seconda fase della sua operazione, mod_gzip controlla le rimanenti regole di filtro che possono essere valutate solo in base al contenuto effettivo del pacchetto di risposta generato:

rspheader (contenuto delle intestazioni della risposta HTTP) così come
mime (tipo di contenuto HTTP del risultato).

Inoltre, ora vengono testate alcune altre condizioni, come la dimensione del pacchetto di risposta (direttive mod_gzip_minimum_file_size rispettivamente mod_gzip_maximum_file_size).

E solo se tutti questi test hanno portato a un risultato positivo, la compressione del pacchetto di risposta verrà effettivamente eseguita.

La posizione di mod_gzip all’interno della sequenza di caricamento di tutti i moduli Apache

Per poter eseguire tutti i compiti descritti sopra, il modulo mod_gzip deve avere accesso alla gestione della richiesta HTTP prima di ogni altro modulo Apache il cui output è destinato a essere gestito. A causa dell’ordine inverso di accesso alla gestione di una richiesta per tutti i moduli Apache, mod_gzip dovrebbe essere caricato come ultimo di tutti i moduli Apache.

Per l’integrazione statica, quest’ordine dei moduli è definito dal ‘progetto’ del programma httpd durante la compilazione del codice sorgente di Apache. La procedura per compilare il codice sorgente di Apache fornito dal Gruppo Apache, attivata dallo script shell configure, conosce tutte le dipendenze tra i moduli forniti (e garantisce un corrispondente ordine di questi moduli) ma non i requisiti dei moduli di terze parti come mod_gzip che sono integrati nel processo di compilazione dal parametro configure –add-module= file. Per consentire il massimo di influenza a questi moduli di terze parti, tali moduli vengono caricati come ultimi moduli nello stack dei moduli.

Quindi, se mod_gzip deve essere integrato in un server Apache come l’unico modulo di terze parti, allora configure fa automaticamente la cosa giusta. Nel caso di utilizzo di più di un modulo di terze parti, l’amministratore è responsabile dell’ordinamento di questi moduli (forse in base all’ordine dei suoi valori –add-module=? Non l’ho ancora testato).

Compilare mod_gzip utilizzando apxs

La funzione dell’utilità di compilazione Apache apxs

Se un server Apache è operato per supportare l’integrazione dinamica dei moduli (cioè utilizza il modulo mod_so), allora un programma di utilità chiamato apxs verrà generato nella directory bin di Apache durante l’installazione di Apache.

Questo programma consente all’utente di compilare il codice sorgente di un modulo Apache (utilizzando un compilatore C) e di creare un corrispondente file oggetto condiviso senza richiedere che il codice sorgente completo dei server Apache sia disponibile: apxs conosce tutte le interfacce di programma Apache richieste e fornisce al compilatore C le informazioni necessarie.

Creare un oggetto condiviso per mod_gzip utilizzando make

Per risparmiare all’utente la fatica di scoprire come esattamente mod_gzip deve essere compilato e installato completamente quando si utilizza apxs, un file chiamato Makefile è fornito all’interno dell’archivio del codice sorgente.

Utilizzando questo Makefile si riduce la procedura di installazione ai seguenti passaggi:

Estrai i file dall’archivio del codice sorgente di mod_gzip scaricato in una directory (nuova, temporanea) a tua scelta e cambia la tua posizione nella directory corrente in essa.
Scopri il nome del percorso del programma apxs dalla tua installazione di Apache.
Esegui la compilazione eseguendo il comando make APXS=*tuo_percorso_apxs* Questo creerà il file oggetto condiviso mod_gzip.so all’interno della directory corrente.
(Questo passaggio della sequenza operativa può essere omesso poiché sarà poi coperto dal passaggio successivo.)
Esegui l’installazione eseguendo il comando make install APXS=*tuo_percorso_apxs* Questo non solo copierà il file oggetto condiviso nella corrispondente directory dell’installazione di Apache, ma estenderà automaticamente anche il file di configurazione di Apache httpd.conf con le direttive richieste LoadModule e AddModule … se non ti piacciono i programmi esterni che riscrivono i tuoi preziosi file di configurazione, potresti preferire eseguire questo passaggio finale manualmente, o almeno fare un backup della tua configurazione di Apache prima.

Oltre a questi passaggi necessari, il Makefile supporta i seguenti comandi (che potrebbero essere di maggiore interesse per gli sviluppatori):

make clean rimuove tutti i file di modulo oggetto creati dai file sorgente di mod_gzip dalla directory corrente (cioè tutti i file con il modello di nome *.o).
make clean aggiuntivamente rimuove anche il file oggetto condiviso creato mod_gzip.so.

Posizione originale di questo documento:

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

mod_gzip - servire contenuti compressi dal server web Apache - Pagina 5