+ <title>Modifications de la configuration à l'exécution</title>
+<p>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.</p>
+
+ <section id="authz">
+ <title>Autorisation</title>
+
+ <p>Tout fichier de configuration qui gère des autorisations devra
+ probablement être mis à jour.</p>
+
+ <p>Vous devez vous reporter au document <a
+ href="howto/auth.html">Authentification, autorisation et contrôle
+ d'accès</a>, et plus particulièrement à la section <a
+ href="howto/auth.html#beyond">Plus loin qu'une simple
+ autorisation</a> qui explique les nouveaux mécanismes permettant de
+ contrôler l'ordre dans lequel les directives d'autorisation sont
+ appliquées.</p>
+
+ <p>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 <directive
+ module="mod_authz_core">RequireAny</directive>, <directive
+ module="mod_authz_core">RequireNone</directive>, et <directive
+ module="mod_authz_core">RequireAll</directive>.</p>
+
+ <p>Si vous utilisez <module>mod_authz_dbm</module>, vous devez
+ mettre à jour votre configuration en remplaçant les directives du
+ style <code>Require group ...</code> par des directives du style
+ <code>Require dbm-group ...</code>.</p>
+
+ <section id="access">
+ <title>Contrôle d'accès</title>
+
+ <p>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 <directive
+ module="mod_access_compat">Order</directive>, <directive
+ module="mod_access_compat">Allow</directive>, <directive
+ module="mod_access_compat">Deny</directive>, et <directive
+ module="mod_access_compat">Satisfy</directive>.</p>
+
+ <p>Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
+ contrôle d'autorisation, par le nouveau module
+ <module>mod_authz_host</module>. Bien que le module
+ <module>mod_access_compat</module> assure la
+ 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.</p>
+
+ <note><title>Mélanger anciennes et nouvelles directives</title>
+ <p>Mélanger d'anciennes directives comme <directive
+ module="mod_access_compat">Order</directive>, <directive
+ module="mod_access_compat">Allow</directive> ou <directive
+ module="mod_access_compat">Deny</directive> avec des nouvelles comme
+ <directive module="mod_authz_core">Require</directive> est techniquement
+ possible mais déconseillé. En effet, <module>mod_access_compat</module> a
+ été conçu pour supporter des configurations ne contenant que des anciennes
+ directives afin de faciliter le passage à la version 2.4. Les
+ exemples ci-dessous vous permettront de vous faire une meilleure idée des
+ problèmes qui peuvent survenir.
+ </p>
+ </note>
+
+ <p>Voici quelques exemples de contrôle d'accès avec l'ancienne et
+ la nouvelle méthode :</p>
+
+ <p>Dans cet exemple, il n'y a pas d'authentification et toutes les
+ requêtes sont rejetées :</p>
+ <example>
+ <title>version 2.2 :</title>
+ <highlight language="config">
+Order deny,allow
+Deny from all
+ </highlight>
+ </example>
+ <example>
+ <title>version 2.4 :</title>
+ <highlight language="config">
+ Require all denied
+ </highlight>
+ </example>
+
+ <p>Dans cet exemple, il n'y a pas d'authentification et toutes les
+ requêtes sont acceptées :</p>
+ <example>
+ <title>version 2.2 :</title>
+ <highlight language="config">
+Order allow,deny
+Allow from all
+ </highlight>
+ </example>
+ <example>
+ <title>version 2.4 :</title>
+ <highlight language="config">
+ Require all granted
+ </highlight>
+ </example>
+
+ <p>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 :</p>
+
+ <example>
+ <title>version 2.2 :</title>
+ <highlight language="config">
+Order Deny,Allow
+Deny from all
+Allow from example.org
+ </highlight>
+ </example>
+ <example>
+ <title>version 2.4 :</title>
+ <highlight language="config">
+ Require host example.org
+ </highlight>
+ </example>
+
+ <p>Dans l'exemple suivant, le mélange d'anciennes et de nouvelles
+ directives produit des résultats inattendus.</p>
+
+ <example>
+ <title>Mélange d'anciennes et de nouvelles directives : RESULTAT
+ INATTENDU</title>
+ <highlight language="config">
+DocumentRoot "/var/www/html"
+
+<Directory "/">
+ AllowOverride None
+ Order deny,allow
+ Deny from all
+</Directory>
+
+<Location "/server-status">
+ SetHandler server-status
+ Require local
+</Location>
+
+access.log - GET /server-status 403 127.0.0.1
+error.log - AH01797: client denied by server configuration: /var/www/html/server-status
+ </highlight>
+ </example>
+ <p>Pourquoi httpd interdit l'accès à server-status alors que la
+ configuration semble l'autoriser ? Parce que dans ce scénario de <a
+ href="sections.html#merging">fusion</a> de configuration, les
+ directives de <module>mod_access_compat</module> sont prioritaires par
+ rapport à celles de <module>mod_authz_host</module>.</p>
+
+ <p>L'exemple suivant quant à lui produit un résultat conforme :</p>
+
+ <example>
+ <title>Mélange d'anciennes et de nouvelles directives : RESULTAT
+ CONFORME</title>
+ <highlight language="config">
+DocumentRoot "/var/www/html"
+
+<Directory "/">
+ AllowOverride None
+ Require all denied
+</Directory>
+
+<Location "/server-status">
+ SetHandler server-status
+ Order deny,allow
+ Deny from all
+ Allow From 127.0.0.1
+</Location>
+
+access.log - GET /server-status 200 127.0.0.1
+ </highlight>
+ </example>
+ <p>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.
+ </p>
+ </section>
+
+
+ <p>Dans de nombreuses configurations avec authentification où la directive
+ <directive>Satisfy</directive> était définie à sa valeur par défaut
+ <em>ALL</em>, les lignes de configuration qui désactivent le contrôle
+ d'accès basé sur l'hôte sont maintenant omises :</p>
+
+ <example>
+ <title>Version 2.2 :</title>
+ <highlight language="config">
+# configuration en version 2.2 qui désactive le contrôle d'accès basé sur le nom
+# d'hôte pour n'utiliser que l'authentification
+Order Deny,Allow
+Allow from all
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
+ </highlight>
+ </example>
+ <example>
+ <title>Version 2.4 :</title>
+ <highlight language="config">
+# Pas besoin de remplacer les directives Order et deny pour les désactiver
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
+ </highlight>
+ </example>
+
+ <p>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
+ <em>deux</em> critères sont acceptées :</p>
+ <example>
+ <title>Version 2.2 :</title>
+ <highlight language="config">
+Order allow,deny
+Deny from all
+# ALL est la valeur par défaut de Satisfy
+Satisfy ALL
+Allow from 127.0.0.1
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
+ </highlight>
+ </example>
+ <example>
+ <title>Version 2.4 :</title>
+ <highlight language="config">
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+<RequireAll>
+ Require valid-user
+ Require ip 127.0.0.1
+</RequireAll>
+ </highlight>
+ </example>
+
+ <p>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 à
+ <em>au moins un</em> critère sont acceptées :</p>
+ <example>
+ <title>Version 2.2 :</title>
+ <highlight language="config">
+Order allow,deny
+Deny from all
+Satisfy any
+Allow from 127.0.0.1
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
+ </highlight>
+ </example>
+ <example>
+ <title>Version 2.4 :</title>
+ <highlight language="config">
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+# Implicite : <RequireAny>
+Require valid-user
+Require ip 127.0.0.1
+ </highlight>
+ </example>
+
+ </section>
+
+ <section id="config">
+ <title>Autres changements dans la configuration</title>
+
+ <p>D'autres ajustements mineurs peuvent s'avérer nécessaires pour
+ certaines configurations particulières, comme décrit ci-dessous.</p>
+
+ <ul>
+ <li><directive>MaxRequestsPerChild</directive> a été renommée en
+ <directive module="mpm_common">MaxConnectionsPerChild</directive>;
+ ce nouveau nom reflète mieux l'usage de cette directive.
+ L'ancien nom est encore supporté.</li>
+
+ <li>La directive <directive>MaxClients</directive> a
+ été renommée en <directive
+ module="mpm_common">MaxRequestWorkers</directive>; ce nouveau
+ nom reflète mieux l'usage de cette directive. Pour les
+ modules multiprocessus asynchrones, comme <module>event</module>, le nombre
+ maximal de clients n'est pas équivalent au nombre de threads du
+ worker. L'ancien nom est encore supporté.</li>
+
+ <li>La directive <directive
+ module="core">DefaultType</directive> ne produit plus aucun
+ effet, si ce n'est d'émettre un avertissement si elle est
+ définie à une valeur autre que <code>none</code>. D'autres
+ directives de configuration la remplacent dans la version 2.4.
+ </li>
+
+ <li>La valeur par défaut de la directive <directive
+ module="core">AllowOverride</directive> est maintenant
+ <code>None</code>.</li>
+
+ <li>La valeur par défaut de la directive <directive
+ module="core">EnableSendfile</directive> est maintenant Off.</li>
+
+ <li>La valeur par défaut de la directive <directive
+ module="core">FileETag</directive> est maintenant "MTime Size"
+ (sans INode).</li>
+
+ <li><module>mod_dav_fs</module>: le format du fichier <directive
+ module="mod_dav_fs">DavLockDB</directive> a changé pour les systèmes
+ avec inodes. L'ancien fichier <directive
+ module="mod_dav_fs">DavLockDB</directive> doit être supprimé dans le
+ cadre de la mise à jour.
+ </li>
+
+ <li>La directive <directive module="core">KeepAlive</directive>
+ n'accepte que les valeurs <code>On</code> ou <code>Off</code>.
+ Avant, toute valeur autre que "Off" ou "0" était traitée comme
+ "On".</li>
+
+ <li>Les directives AcceptMutex, LockFile, RewriteLock, SSLMutex,
+ SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la
+ directive unique <directive module="core">Mutex</directive>.
+ 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 <directive
+ module="core">Mutex</directive>.</li>
+
+ <li><module>mod_cache</module>: la directive <directive
+ module="mod_cache">CacheIgnoreURLSessionIdentifiers</directive>
+ 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
+ <code>sessionid</code> pour correspondre à
+ <code>/une-application/image.gif;jsessionid=123456789</code>,
+ vous devez maintenant utiliser la chaîne de correspondance
+ complète <code>jsessionid</code>.
+ </li>
+
+ <li><module>mod_cache</module>: le second paramètre de la
+ directive <directive module="mod_cache">CacheEnable</directive>
+ 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.</li>
+
+ <li><module>mod_ldap</module>: la directive <directive
+ module="mod_ldap">LDAPTrustedClientCert</directive> 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.</li>
+
+ <li><module>mod_filter</module>: la syntaxe de la directive
+ <directive module="mod_filter">FilterProvider</directive> utilise
+ maintenant une expression booléenne pour déterminer si un filtre
+ s'applique.
+ </li>
+
+ <li><module>mod_include</module>:
+ <ul>
+ <li>L'élément <code>#if expr</code> utilise maintenant le
+ nouvel <a href="expr.html">interpréteur d'expressions</a>.
+ L'ancienne syntaxe peut être réactivée via la directive
+ <directive
+ module="mod_include">SSILegacyExprParser</directive>.
+ </li>
+ <li>Dans la portée du répertoire, une directive de
+ configuration SSI* ne provoque plus la réinitialisation à
+ leur valeur par défaut de toutes les directives SSI* de
+ niveau répertoire.</li>
+ </ul>
+ </li>
+
+ <li><module>mod_charset_lite</module> : l'option
+ <code>DebugLevel</code> a été supprimée en faveur d'une
+ configuration de la directive <directive
+ module="core">LogLevel</directive> au niveau répertoire.
+ </li>
+
+ <li><module>mod_ext_filter</module> : l'option
+ <code>DebugLevel</code> a été supprimée en faveur d'une
+ configuration de la directive <directive
+ module="core">LogLevel</directive> au niveau répertoire.
+ </li>
+
+ <li><module>mod_proxy_scgi</module>: certaines applications web
+ ne fonctionneront plus correctement avec la nouvelle
+ configuration de <code>PATH_INFO</code> 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
+ <code>proxy-scgi-pathinfo</code>.</li>
+
+ <li><module>mod_ssl</module>: le contrôle de révocation des
+ certificats basé sur les CRL doit être maintenant explicitement
+ configuré via la directive <directive
+ module="mod_ssl">SSLCARevocationCheck</directive>.
+ </li>
+
+ <li><module>mod_substitute</module>: la taille maximale d'une
+ ligne est maintenant 1Mo.
+ </li>
+
+ <li><module>mod_reqtimeout</module>: si ce module est chargé, il
+ définit maintenant certains temps d'attente par défaut.</li>
+
+ <li><module>mod_dumpio</module>: la directive
+ <directive>DumpIOLogLevel</directive> n'est plus supportée. Les
+ données sont toujours enregistrées au niveau <code>trace7</code>
+ de <directive module="core">LogLevel</directive></li>
+
+ <li>Jusqu'à la version 2.2, sur les plateformes de style Unix,
+ les commandes de redirection des logs définies via <directive
+ module="core">ErrorLog</directive> ou <directive
+ module="mod_log_config">CustomLog</directive> étaient invoquées
+ en utilisant <code>/bin/sh -c</code>. 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 <a href="logs.html#piped">documentation
+ sur la redirection des logs</a></li>