mod_gzip - servir du contenu compressé par le serveur web Apache - Page 8

Auteur : Michael Schröpl

Ce document décrit quelques améliorations fonctionnelles possibles qui, espérons-le, pourraient être mises en œuvre dans la version actuelle 1.3.26.1a de mod_gzip sans trop d’effort et améliorer l’utilisabilité de ce module.

Classe de journalisation et valeur de la règle de filtre décisive

La décision de savoir si le contenu d’un document est éligible à la compression par mod_gzip est finalement prise lors de l’évaluation des règles de filtre définies par les directives mod_gzip_item_include et mod_gzip_item_exclude qui sont vérifiées par la fonction mod_gzip_validate1.

Mais cette fonction est invoquée à pas moins de cinq endroits dans le code source, chaque fois avec des paramètres différents pour des parties spécifiques des classes de règles à vérifier à ce moment-là. Dans certains de ces cas, il est clair d’après le paramètre restreint quelle classe de règle doit avoir conduit au résultat spécifique (mais pas quelle valeur de règle !), dans d’autres cas (comme le test simultané de toutes les règles des classes file, uri, mime et handler) même la classe de la règle décisive n’est pas claire (car mod_gzip_validate1 renvoie une valeur de résultat si peu spécifique au demandeur qu’il ne peut même pas comprendre ce qui s’est exactement passé - dans certains cas, même des erreurs internes sont encodées comme une décision en raison d’une règle d’exclusion). Dans ces cas, même une évaluation raisonnable du code d’état mod_gzip n’est pas possible.

Mais la définition d’un ensemble de règles approprié est l’étape la plus importante durant l’ensemble de la procédure de configuration mod_gzip (et actuellement encore plutôt compliquée). Toute information sur laquelle des règles définies a décidé dans quels cas si le contenu d’un document devait être compressé serait utile pour l’utilisateur dans de nombreux cas.

D’autre part, mod_gzip prend déjà en charge la transparence de traitement après avoir traité avec succès un document en définissant certaines variables qui peuvent être utilisées dans les formats de journal Apache (le statut de traitement, les tailles de document avant et après compression ainsi que le volume économisé en pourcentage - ce dernier étant erronément toujours arrondi à la hausse). Selon cela, mod_gzip pourrait (juste au moment où la décision de compresser le contenu du document a été prise) facilement stocker la classe et le contenu de la règle décisive dans deux autres variables de journal qui seraient ensuite adressées dans un format de journal via les noms mod_gzip_rule_class et mod_gzip_rule_content.

Niveau de compression gzip configurable

Actuellement, mod_gzip utilise le niveau de compression gzip 6. Cela est codé en dur par l’assignation gz1->level = 6 à l’intérieur de la fonction gz1_init.

Plus le niveau de compression est élevé (gzip autorise des valeurs entre 1 et 9), meilleur est l’effet de compression, mais plus la consommation de temps CPU est élevée également. En adaptant ce niveau de compression, un utilisateur pourrait résoudre le compromis entre la charge CPU et l’économie de bande passante selon ses propres exigences. Des expériences personnelles ont montré que le niveau 3 vous rapproche déjà de l’effet du niveau de compression 6 - du moins le choix entre ces deux valeurs devrait être laissé à l’utilisateur.

Ainsi, il serait raisonnable d’avoir ce niveau de compression configurable en offrant une autre directive mod_gzip_compression_level.

Un examen plus approfondi par Christian Kruse a conduit à la conclusion que le code de compression de Kevin Kiley pour mod_gzip ne semble pas prendre en charge tous les 9 niveaux de compression pour

gzip

mais fondamentalement juste ceux requis pour le niveau 6 (bien que la structure du programme ait été conçue pour implémenter tous les 9 niveaux plus tard). Par conséquent, il ne suffit pas de simplement changer la constante susmentionnée ; en fait, mod_gzip n’est même plus utilisable après ce type de modification.

Expressions booléennes dans les directives include / exclude

mod_gzip 1.3.19.1a utilise - causé par sa façon d’être intégré dans le traitement des requêtes Apache - une procédure de filtre complexe à deux niveaux pour décider si le résultat d’une requête doit être compressé. (Dans une architecture modifiée d’Apache 2.0, une méthode d’intégration plus simple pourrait être possible.)

Une requête sera actuellement acceptée par mod_gzip exactement si, lors de chaque phase de décision, au moins une règle include est déclenchée mais aucune règle exclude. Comme ces règles permettent des expressions régulières comme valeurs de paramètres, cela rend disponibles des conditions puissantes.

Néanmoins, toutes les règles sont indépendantes les unes des autres ; les directives actuellement disponibles ne permettent pas à l’utilisateur d’exprimer que des types MIME distincts ne soient livrés qu’en forme compressée à des navigateurs distincts - la connexion ET entre plusieurs règles fait défaut.

Il semble qu’il n’y ait que de rares occasions où cela serait vraiment utile - jusqu’à présent, il serait particulièrement nécessaire d’affiner les règles de filtre pour faire face à tous les bugs de Netscape 4, autrement qu’en excluant totalement ce navigateur de la compression. Avec le temps qui passe (et l’amélioration de la conformité aux normes des navigateurs), cette fonctionnalité pourrait devenir obsolète.

Servir des en-têtes HTTP identiques pour les requêtes GET et HEAD

Selon la RFC 2616, pour une requête utilisant la méthode HEAD, une implémentation conforme à HTTP/1.1 devrait servir des en-têtes HTTP identiques à ceux qui auraient été servis pour une requête pour la même ressource utilisant la méthode GET.

Dans le cas de mod_gzip, cela signifierait que même pour une requête HEAD, le contenu devrait être compressé (resp. lu, dans le cas d’un fichier précompressé statiquement) juste pour pouvoir générer un en-tête HTTP Content-Length correct.

À l’heure actuelle, mod_gzip ne gère pas ce cas (extrêmement rare) d’application (probablement en raison de considérations de performance) ; pourtant, selon la RFC 2119, cela pourrait amener le comportement du module à être donc seulement conditionnellement compatible avec HTTP/1.1 car il doit y avoir une raison valable pour ne pas soutenir une exigence recommandée.

Emplacement original de ce document :

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