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 :
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 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
Si vous utilisez 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
Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
+ contrôle d'autorisation, par le nouveau module
+
Mélanger d'anciennes directives comme
Voici quelques exemples de contrôle d'accès avec l'ancienne et + la nouvelle méthode :
+ +Dans cet exemple, il n'y a pas d'authentification et toutes les + requêtes sont rejetées :
+Dans cet exemple, il n'y a pas d'authentification et toutes les + requêtes sont acceptées :
+Dans l'exemple suivant, il n'y a pas d'authentification et tous les + hôtes du domaine example.org + ont l'autorisation d'accès, tous les autres étant rejetés :
+ +Dans l'exemple suivant, le mélange d'anciennes et de nouvelles + directives produit des résultats inattendus.
+ +Pourquoi httpd interdit l'accès à server-status alors que la
+ configuration semble l'autoriser ? Parce que dans ce scénario de fusion de configuration, les
+ directives de
L'exemple suivant quant à lui produit un résultat conforme :
+ +En conclusion, même si une configuration hybride peut fonctionner, + essayez de l'éviter lors de la mise à jour : soit conservez les anciennes + directives, puis migrez-les vers les nouvelles ultérieurement, soit + effectuez une migration immédiate de toutes les anciennes directives vers + les nouvelles. +
+Dans de nombreuses configurations avec authentification où la directive
+
Dans les configurations où l'authentification et le contrôle d'accès se + combinaient dans un but précis, les directives de contrôle d'accès doivent + être migrées. Dans l'exemple suivant, les requêtes qui correspondent aux + deux critères sont acceptées :
+Dans les configurations où l'authentification et le contrôle d'accès se + combinaient dans un but précis, les directives de contrôle d'accès doivent + être migrées. Dans l'exemple suivant, les requêtes qui correspondent à + au moins un critère sont acceptées :
+D'autres ajustements mineurs peuvent s'avérer nécessaires pour + certaines configurations particulières, comme décrit ci-dessous.
+ +none. D'autres
+ directives de configuration la remplacent dans la version 2.4.
+ None.On ou Off.
+ Avant, toute valeur autre que "Off" ou "0" était traitée comme
+ "On".sessionid pour correspondre Ã
+ /une-application/image.gif;jsessionid=123456789,
+ vous devez maintenant utiliser la chaîne de correspondance
+ complète jsessionid.
+ #if expr utilise maintenant le
+ nouvel interpréteur d'expressions.
+ L'ancienne syntaxe peut être réactivée via la directive
+ DebugLevel a été supprimée en faveur d'une
+ configuration de la directive DebugLevel a été supprimée en faveur d'une
+ configuration de la directive 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.trace7
+ de /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 logs*_DN a changé. Il est cependant encore possible
+ d'utiliser l'ancien format via la nouvelle option
+ LegacyDNStringFormat de la directive #if expr=
+ du module mod_authn_alias
+ dans les précédentes versions (en fait la directive
+ 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 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 Ignoring deprecated use of DefaultType in line NN of
+ /path/to/httpd.conf - supprimez la directive Invalid command 'AddOutputFilterByType', perhaps misspelled
+ or defined by a module not included in the server configuration
+ - la directive configuration error: couldn't check user: /path -
+ chargez le module .htaccess ne sont pas traités -
+ Vérifiez la présence d'une directive None.