Serveur HTTP Apache Version 2.4
Serveur HTTP Apache Version 2.4
Ce document décrit quelques uns des changements principaux entre les versions 2.0 et 2.2 du serveur HTTP Apache. Pour les nouvelles fonctionnalités ajoutées depuis la version 1.3, se référer au document 2.0 new features.
Améliorations du système de base Améliorations des modules Améliorations des programmes Changements pour le développeur de module
mod_cache, mod_cache_disk, et
mod_mem_cache (supprimés dans la version 2.3/2.4) ont subi de nombreuses
modifications, et l'on considère qu'ils ont maintenant atteint
un degré de qualité suffisant pour leur mise en production. Le programme
htcacheclean a été ajouté afin de rendre
plus propre la configuration du module
mod_cache_disk.prefork,
worker et event permettent
maintenant l'arrêt en douceur de httpd
au moyen du signal
graceful-stop.
La directive GracefulShutdownTimeout a été ajoutée dans le but
de spécifier un délai optionnel, après lequel
httpd s'arrêtera quel que soit le statut
des requêtes en cours.mod_proxy_balancer fournit
des services de répartition de charge (load balancing) pour le
module mod_proxy.
Le nouveau module mod_proxy_ajp ajoute le
support pour le
Protocole JServ de Apache version 1.3 qu'utilise
Apache Tomcat.httpd peut être configuré pour utiliser une
PCRE choisie en passant l'option --with-pcre au
script configure.mod_filter permet la configuration
dynamique de la chaîne de filtrage en sortie. Il permet
d'insérer des filtres conditionnels basés sur toute
requête, en-tête de réponse ou variable
d'environnement, et fait table rase des problèmes de dépendances
et d'ordonnancement rencontrés avec l'architecture 2.0.httpd supporte maintenant les fichiers d'une taille supérieure
à 2GB sur les systèmes 32 bits UNIX modernes. Le support des
corps de requête d'une taille supérieure à 2GB a aussi été
ajouté.event utilise un thread séparé
pour gérer les requêtes "Keep alive" et accepter des connexions.
Les requêtes "Keep alive" requéraient traditionnellement un
processus httpd dédié pour leur gestion. Ce processus dédié
ne pouvait plus être réutilisé jusqu'à ce que le délai "Keep Alive"
soit écoulé.mod_dbd, associé à l'environnement
apr_dbd, fournit le support SQL direct aux modules
qui en ont besoin. Supporte la mise en commun des connexions
dans les modules MPM threadés.mod_auth
est maintenant scindé en deux modules : mod_auth_basic et
mod_authn_file; mod_auth_dbm s'appelle maintenant
mod_authn_dbm; mod_access a été renommé en
mod_authz_host. Est également apparu le nouveau module
mod_authn_alias (supprimé dans la version 2.3/2.4) qui simplifie
certaines configurations d'authentification.
mod_authnz_ldapmod_auth_ldap vers la version 2.2 du framework
Authn/Authz.
Les nouvelles fonctionnalités comprennent l'utilisation des valeurs
d'attributs LDAP et des filtres de recherche avancés dans la
directive Require.mod_authz_ownermod_versionmod_info?config a été ajouté, qui permettra d'afficher
les directives de configuration telles qu'elles sont interprétées
par Apache, y compris le nom de fichier et le numéro de ligne.
Le module montre aussi l'ordre des points d'entrée de traitement d'une
requête (request hooks) ainsi que des informations de construction
supplémentaires, d'une manière similaire à httpd -V.mod_sslmod_imagemapmod_imap a été renommé en mod_imagemap afin
d'éviter une confusion pour les utilisateurs.httpd-M
a été ajoutée, qui fournit la liste de tous les modules chargés
en fonction de la configuration réelle. À la différence de l'option
-l, cette liste inclut les Objets Dynamiques Partagés
(DSOs) chargés par l'intermédiaire du module
mod_so.httxt2dbmRewriteMap
et le type de mise en correspondance dbm.APR et
APR-Util. Pour plus de détails, consultez le
site web d'APR.mod_auth_* -> Modules qui implémentent un mécanisme
d'authentification HTTPmod_authn_* -> Modules qui fournissent un dispositif
d'authentification en arrière-planmod_authz_* -> Modules qui implémentent l'autorisation (ou l'accès)mod_authnz_* -> Modules qui implémentent à la fois
l'authentification & l'autorisationap_log_cerror,
afin de pouvoir enregistrer les erreurs qui surviennent au cours de
la connexion du client. Une fois enregistré, le message inclut l'adresse IP du client.test_config,
afin d'aider les modules qui ne veulent exécuter un code spécial
que si l'utilisateur passe le paramètre -t à
httpd.ThreadStackSize
afin de définir la taille de la pile pour tous les modules MPM en processus légers (modules threadés).
Ceci s'avère nécessaire pour certains modules tiers sur des plateformes
dont la taille de la pile des threads par défaut est
trop petite.mod_filter, à l'aide des appels
ap_register_output_filter_protocol ou
ap_filter_protocol.pcreposix.h n'est plus disponible ;
il a été remplacé par le nouveau fichier
d'en-tête ap_regex.h. L'implémentation
POSIX.2 regex.h exposée dans l'ancien fichier d'en-tête
est maintenant disponible dans l'espace de nommage ap_
depuis ap_regex.h. Les appels à regcomp,
regexec, etc... peuvent être remplacés par des appels à
ap_regcomp, ap_regexec.Avec Apache 1.x et 2.0, les modules nécessitant un processus SQL d'arrière-plan devaient s'en charger eux-mêmes. En dehors du fait de réinventer la roue, ceci peut s'avérer très inefficace, par exemple lorsque plusieurs modules maintiennent chacun leurs propres connexions.
Apache 2.1 et supérieur fournissent l'API ap_dbd qui
permet la gestion des connexions à la base de données (y compris
les stratégies optimisées pour les modules MPM threadés
et non threadés), tandis que APR 1.2 et supérieur fournissent
l'API apr_dbd qui permet l'interaction avec la
base de données.
Les nouveaux modules DEVRAIENT désormais utiliser ces APIs pour toutes les opérations liées aux bases de données SQL. De même, les applications existantes DEVRAIENT être mises à jour lorsque c'est possible, que ce soit de manière transparente ou sous forme d'une option recommandée à leurs utilisateurs.