Serveur Apache HTTP Version 2.4
Afin d'assister les utilisateurs lors de leurs opérations de mise à
jour, nous maintenons un document
qui comporte des informations critiques à l'attention des personnes qui
utilisent déjà le serveur HTTP Apache. Ces informations
ne sont que de brèves notes, et vous
trouverez plus d'informations dans le document Nouvelles fonctionnalités, ou dans
le fichier src/CHANGES
. Les développeurs d'applications
et de modules trouveront un résumé des modifications de l'API dans la
vue d'ensemble Mises à jour de
l'API.
Ce document présente les changements de comportement du serveur qui peuvent nécessiter une modification de la configuration, et une méthode pour utiliser la version 2.4 du serveur en parallèle avec la version 2.2. Pour tirer parti des nouvelles fonctionnalités de la version 2.4, reportez-vous au document "Nouvelles fonctionnalités".
Ce document ne décrit que les modifications intervenues entre les versions 2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous devez aussi consulter le document de mise à jour de 2.0 vers 2.2.
Le processus de compilation est très similaire à celui de la
version 2.2. Dans la plupart des cas, vous pourrez utiliser votre
ancienne ligne de commande configure
(telle qu'elle
est enregistrée dans le fichier build/config.nice
situé dans le répertoire de compilation du serveur). Voici certains
changements intervenus dans la configuration par défaut :
mod_cache_disk
dans la version 2.4.mod_lbmethod_bybusyness
. Vous devrez compiler et
chargés tous les modules correspondants que votre configuration
utilise.LoadModule
sont mises en commentaires dans le fichier de configuration.Des changements significatifs dans la configuration de l'autorisation, ainsi que quelques changements mineurs, peuvent nécessiter une mise à jour des fichiers de configuration de la version 2.2 avant de les utiliser sous la version 2.4.
Tout fichier de configuration qui gère des autorisations devra probablement être mis à jour.
Vous devez vous reporter au document Authentification, autorisation et contrôle d'accès, et plus particulièrement à la section Pour aller plus loin qu'une simple autorisation qui explique les nouveaux mécanismes permettant de contrôler l'ordre dans lequel les directives d'autorisation sont appliquées.
Les directives qui contrôlent la manière dont les modules
d'autorisation réagissent lorsqu'ils ne reconnaissent pas
l'utilisateur authentifié ont été supprimées : elles comprennent les
directives AuthzLDAPAuthoritative, AuthzDBDAuthoritative,
AuthzDBMAuthoritative, AuthzGroupFileAuthoritative,
AuthzUserAuthoritative et AuthzOwnerAuthoritative. Ces directives
ont été remplacées par les directives plus explicites RequireAny
, RequireNone
, et RequireAll
.
Si vous utilisez mod_authz_dbm
, vous devez
mettre à jour votre configuration en remplaçant les directives du
style Require group ...
par des directives du style
Require dbm-group ...
.
Dans la version 2.2, le contrôle d'accès basé sur le nom d'hôte
du client, son adresse IP, ou d'autres caractéristiques de la
requête était assuré via les directives Order
, Allow
, Deny
, et Satisfy
.
Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
contrôle d'autorisation, par le nouveau module
mod_authz_host
. Bien que le module
mod_access_compat
soit fourni à des fins de
compatibilité avec les anciennes configurations, les anciennes
directives de contrôle d'accès devront être remplacées par les
nouveaux mécanismes d'authentification.
Voici quelques exemples de contrôle d'accès avec l'ancienne et la nouvelle méthode :
Dans cet exemple, toutes les requêtes sont rejetées :
Order deny,allow Deny from all
Require all denied
Dans cet exemple, toutes les requêtes sont acceptées :
Order allow,deny Allow from all
Require all granted
Dans l'exemple suivant, tous les hôtes du domaine example.org ont l'autorisation d'accès, tous les autres sont rejetés :
Order Deny,Allow Deny from all Allow from example.org
Require host example.org
D'autres ajustements mineurs peuvent s'avérer nécessaires pour certaines configurations particulières, comme décrit ci-dessous.
MaxRequestsPerChild
a été renommée en
MaxConnectionsPerChild
;
ce nouveau nom reflète mieux l'usage de cette directive.
L'ancien nom est encore supporté.MaxClients
a
été renommée en MaxRequestWorkers
; ce nouveau
nom reflète mieux l'usage de cette directive. Pour les
modules multiprocessus asynchrones, comme event
, le nombre
maximal de clients n'est pas équivalent au nombre de threads du
worker. L'ancien nom est encore supporté.DefaultType
ne produit plus aucun
effet, si ce n'est d'émettre un avertissement si elle est
définie à une valeur autre que none
. D'autres
directives de configuration la remplacent dans la version 2.4.
AllowOverride
est maintenant
None
.EnableSendfile
est maintenant Off.FileETag
est maintenant "MTime Size"
(sans INode).mod_dav_fs
: le format du fichier DavLockDB
a changé pour les systèmes
avec inodes. L'ancien fichier DavLockDB
doit être supprimé dans le
cadre de la mise à jour.
KeepAlive
n'accepte que les valeurs On
ou Off
.
Avant, toute valeur autre que "Off" ou "0" était traitée comme
"On".Mutex
.
Vous devez évaluer l'impact de ces directives obsolètes dans
votre configuration version 2.2 afin de déterminer si elles
peuvent être simplement supprimées, ou si elles doivent être
remplacées par la directive Mutex
.mod_cache
: la directive CacheIgnoreURLSessionIdentifiers
effectue maintenant une correspondance exacte dans la chaîne de
paramètres au lieu d'une correspondance partielle. Si votre
configuration mettait en jeu des sous-chaînes comme
sessionid
pour correspondre à
/une-application/image.gif;jsessionid=123456789
,
vous devez maintenant utiliser la chaîne de correspondance
complète jsessionid
.
mod_cache
: le second paramètre de la
directive CacheEnable
ne concerne les contenus en mandat direct que s'ils débutent par
le protocole approprié. Dans les versions 2.2 et antérieures, un
paramètre tel que '/' concernait tous les contenus.mod_ldap
: la directive LDAPTrustedClientCert
s'utilise
maintenant exclusivement au sein d'une configuration de niveau
répertoire. Si vous utilisez cette directive, passez en revue
votre configuration pour vous assurer qu'elle est bien présente
dans tous les contextes de répertoire nécessaires.mod_filter
: la syntaxe de la directive
FilterProvider
utilise
maintenant une expression booléenne pour déterminer si un filtre
s'applique.
mod_include
:
#if expr
utilise maintenant le
nouvel interpréteur d'expressions.
L'ancienne syntaxe peut être réactivée via la directive
SSILegacyExprParser
.
mod_charset_lite
: l'option
DebugLevel
a été supprimée en faveur d'une
configuration de la directive LogLevel
au niveau répertoire.
mod_ext_filter
: l'option
DebugLevel
a été supprimée en faveur d'une
configuration de la directive LogLevel
au niveau répertoire.
mod_proxy_scgi
: certaines applications web
ne fonctionneront plus correctement avec la nouvelle
configuration de PATH_INFO
qui est différente de
celle de la version 2.2. La configuration
précédente peut être
restaurée en définissant la variable
proxy-scgi-pathinfo
.mod_ssl
: le contrôle de révocation des
certificats basé sur les CRL doit être maintenant explicitement
configuré via la directive SSLCARevocationCheck
.
mod_substitute
: la taille maximale d'une
ligne est maintenant 1Mo.
mod_reqtimeout
: si ce module est chargé, il
définit maintenant certains temps d'attente par défaut.mod_dumpio
: la directive
DumpIOLogLevel
n'est plus supportée. Les
données sont toujours enregistrées au niveau trace7
de LogLevel
ErrorLog
ou CustomLog
étaient invoquées
en utilisant /bin/sh -c
. A
partir de la version 2.4, les commandes de redirection des logs
sont exécutées directement. Pour retrouver l'ancien
comportement, voir la documentation
sur la redirection des logsmod_auto_index
: extrait maintenant les titres
et affiche la description pour les fichiers .xhtml qui étaient
jusqu'alors ignorés.mod_ssl
: le format par défaut des variables
*_DN
a changé. Il est cependant encore possible
d'utiliser l'ancien format via la nouvelle option
LegacyDNStringFormat
de la directive SSLOptions
. Le protocole SSLv2 n'est
plus supporté. Les directives SSLProxyCheckPeerCN
et
SSLProxyCheckPeerExpire
sont maintenant définies par défaut à On, et les requêtes mandatées
vers des serveurs HTTPS possèdant des certificats non conformes ou
périmés échoueront donc avec un code d'erreur 502 (Bad gateway).htpasswd
utilise maintenant par défaut les
condensés MD5 sur toutes les plates-formes.NameVirtualHost
n'a plus aucun effet, si
ce n'est l'émission d'un avertissement. Toute combinaison
adresse/port apparaissant dans plusieurs serveurs virtuels est
traitée implicitement comme un serveur virtuel basé sur le nom.
mod_deflate
n'effectue plus de compression
s'il s'aperçoit que la quantité de données ajoutée par la
compression est supérieure à la quantité de données à compresser.
#if expr=
du module mod_include
, ou si la directive
SSILegacyExprParser
a
été activée pour le répertoire contenant les pages d'erreur.
mod_authn_alias
dans les précédentes versions (en fait la directive
AuthnProviderAlias
)
est maintenant fournie par mod_authn_core
.
LogLevel
qui permet de définir
un niveau de journalisation approprié pour le module
mod_rewrite
. Voir aussi la section journalisation de
mod_rewrite.Tous les modules tiers doivent être recompilés pour la version 2.4 avant d'être chargés.
De nombreux modules tiers conçus pour la version 2.2 fonctionneront sans changement avec le serveur HTTP Apache version 2.4. Certains nécessiteront cependant des modifications ; se reporter à la vue d'ensemble Mise à jour de l'API.
Invalid command 'User', perhaps misspelled or defined by
a module not included in the server configuration
- chargez
le module mod_unixd
Invalid command 'Require', perhaps misspelled or defined
by a module not included in the server configuration
, ou
Invalid command 'Order', perhaps misspelled or defined by a
module not included in the server configuration
- chargez
le module mod_access_compat
, ou mettez à jour
vers la version 2.4 les directives d'autorisation.Ignoring deprecated use of DefaultType in line NN of
/path/to/apache2.conf
- supprimez la directive DefaultType
et remplacez-la par les
directives de configuration appropriées.Invalid command 'AddOutputFilterByType', perhaps misspelled
or defined by a module not included in the server configuration
- la directive AddOutputFilterByType
qui était
jusqu'alors implémentée par le module core, l'est maintenant par
le module mod_filter, qui doit donc être chargé.configuration error: couldn't check user: /path
-
chargez le module mod_authn_core
..htaccess
ne sont pas traités -
Vérifiez la présence d'une directive AllowOverride
appropriée ; sa valeur par
défaut est maintenant None
.