Serveur Apache HTTP 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 modulemod_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.