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

Autore: Michael Schröpl

Questo documento descrive alcuni possibili miglioramenti funzionali che speriamo possano essere implementati nella versione attuale 1.3.26.1a di mod_gzip senza troppi sforzi e migliorare l’usabilità di questo modulo.

Classe di registrazione e valore della regola di filtro decisiva

La decisione su se il contenuto di un documento si qualifichi per la compressione tramite mod_gzip viene infine presa durante la valutazione delle regole di filtro definite dalle direttive mod_gzip_item_include e mod_gzip_item_exclude che vengono controllate dalla funzione mod_gzip_validate1.

Ma questa funzione viene invocata in non meno di cinque posizioni all’interno del codice sorgente, ogni volta con impostazioni di parametro diverse per parti specifiche delle classi di regole da controllare in quel momento. In alcuni di questi casi è chiaro dall’impostazione dei parametri ristretti quale classe di regole deve aver portato al risultato specifico (ma non quale valore di regola!), in altri casi (come il test simultaneo di tutte le regole delle classi file, uri, mime e handler) nemmeno la classe della regola decisiva è chiara (perché mod_gzip_validate1 restituisce un valore di risultato così non specifico al chiamante che questo non può nemmeno capire cosa sia successo esattamente - in alcuni casi anche errori interni sono codificati come una decisione a causa di una regola di esclusione). In questi casi non è nemmeno possibile una valutazione ragionevole del codice di stato di mod_gzip.

Ma la definizione di un insieme di regole appropriato è il passo più importante durante l’intera (e attualmente ancora piuttosto complicata) procedura di configurazione di mod_gzip. Qualsiasi informazione su quale delle regole definite ha deciso in quali casi se un contenuto di documento doveva essere compresso sarebbe utile per l’utente in molti casi.

D’altra parte, mod_gzip supporta già la trasparenza del processo dopo aver gestito con successo un documento impostando alcune variabili che possono essere utilizzate nei formati di log di Apache (lo stato del processo, le dimensioni del documento prima e dopo la compressione così come il risparmio di volume in percentuale - quest’ultimo erroneamente sempre arrotondato per eccesso). Secondo questo, mod_gzip potrebbe (proprio nel momento in cui è stata presa la decisione di comprimere il contenuto del documento) memorizzare facilmente classe e contenuto della regola decisiva in due ulteriori variabili di log che verrebbero quindi indirizzate all’interno di un formato di log tramite i nomi mod_gzip_rule_class e mod_gzip_rule_content.

Livello di compressione gzip configurabile

Attualmente mod_gzip utilizza il livello di compressione gzip 6. Questo è codificato nel codice dalla assegnazione gz1->level = 6 all’interno della funzione gz1_init.

Maggiore è il livello di compressione (gzip consente valori tra 1 e 9), migliore è l’effetto di compressione, ma maggiore è anche il consumo di tempo della CPU. Adattando questo livello di compressione, un utente potrebbe risolvere il compromesso tra carico della CPU e risparmio di larghezza di banda secondo le proprie esigenze. Esperimenti personali hanno dimostrato che il livello 3 ti porta già vicino all’effetto del livello di compressione 6 - almeno la scelta tra questi due valori dovrebbe essere lasciata all’utente.

Pertanto sarebbe ragionevole avere questo livello di compressione configurabile offrendo un’altra direttiva mod_gzip_compression_level.

Uno sguardo più attento di Christian Kruse ha portato alla conclusione che il codice di compressione di Kevin Kiley per mod_gzip non sembra supportare tutti i 9 livelli di compressione per

gzip

ma fondamentalmente solo quelli richiesti per il livello 6 (anche se la struttura del programma è stata progettata per implementare tutti e 9 i livelli in seguito). Pertanto, cambiare semplicemente la costante sopra menzionata non è sufficiente; infatti, mod_gzip non è nemmeno più utilizzabile dopo questo tipo di modifica.

Espressioni booleane nelle direttive include / exclude

mod_gzip 1.3.19.1a utilizza - causato dal suo modo di essere incorporato all’interno della gestione delle richieste di Apache - una complessa procedura di filtro a due livelli per decidere se il risultato di una richiesta debba essere compresso. (In un’architettura modificata di Apache 2.0 potrebbe essere possibile un modo più semplice di incorporamento.)

Una richiesta attualmente sarà accettata da mod_gzip esattamente se durante ciascuna delle due fasi decisionali almeno una regola include si attiva ma nessuna regola exclude. Poiché tali regole consentono espressioni regolari come valori di parametro, ciò rende disponibili condizioni potenti.

Tuttavia, tutte le regole sono indipendenti l’una dall’altra; le direttive attualmente disponibili non consentono all’utente di esprimere che tipi MIME distinti siano consegnati solo in forma compressa a browser distinti - la connessione E tra diverse regole è mancante.

Sembra che ci siano solo rare occasioni in cui questo sarebbe davvero utile - fino ad ora, sarebbe particolarmente necessario affinare le regole di filtro per affrontare tutti i bug di Netscape 4, piuttosto che escludere totalmente questo browser dalla compressione. Con il passare del tempo (e il miglioramento della conformità agli standard dei browser) questa funzionalità potrebbe diventare obsoleta.

Servire intestazioni HTTP identiche per richieste GET e HEAD

Secondo la RFC 2616, per una richiesta che utilizza il metodo HEAD, un’implementazione conforme a HTTP/1.1 dovrebbe servire intestazioni HTTP identiche a quelle che sarebbero state servite per una richiesta per la stessa risorsa utilizzando il metodo GET.

Nel caso di mod_gzip, ciò significherebbe che anche per una richiesta HEAD il contenuto dovrebbe essere compresso (rispettivamente letto, nel caso di un file precompresso staticamente) solo per poter generare una corretta intestazione HTTP Content-Length.

Fino ad ora, mod_gzip non gestisce questo (estremamente raro) caso di applicazione (probabilmente a causa di considerazioni sulle prestazioni); tuttavia, secondo la RFC 2119, questo potrebbe causare il comportamento del modulo in modo tale da essere solo condizionatamente compatibile con HTTP/1.1 perché deve esserci una valida ragione per non supportare un requisito raccomandato.

Posizione originale di questo documento:

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