Serveur HTTP Apache Version 2.5

Apache > Serveur HTTP > Documentation > Version 2.5

# Mise à jour de la version 2.2 vers la 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 la manière d'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.

### Voir aussi

- Vue d'ensemble des nouvelles fonctionnalités du serveur HTTP Apache 2.4

## Modifications des paramètres de compilation ¶

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 :

- Les modules suivants ont été supprimés : mod_authn_default, mod_authz_default et mod_mem_cache. Si vous utilisiez mod_mem_cache sous la version 2.2, vous devez maintenant utiliser `mod_cache_disk` dans la version 2.4.
- Toutes les implémentations de répartition de charge ont été déplacées vers des sous-modules spécifiques de mod_proxy, comme `mod_lbmethod_bybusyness`. Vous devrez compiler et chargés tous les modules correspondants que votre configuration utilise.
- Le support de BeOS, TPF, et des anciennes plates-formes telles que A/UX, Next, et Tandem a été supprimé, car elles ne sont plus considérées comme maintenues.
- configure: les modules dynamiques (DSO) sont compilés par défaut
- configure: par défaut, seul un jeu de modules de base est chargé. Les autres directives `LoadModule` sont mises en commentaires dans le fichier de configuration.
- configure: le jeu de modules "most" est compilé par défaut
- configure: le jeu de modules "reallyall" ajoute les modules de développeur au jeu "all".

## Modifications de la configuration à l'exécution ¶

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.

### Autorisation

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 `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 ...`.

#### Contrôle d'accès

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` 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.

### Mélanger anciennes et nouvelles directives

Mélanger d'anciennes directives comme `Order`, `Allow` ou `Deny` avec des nouvelles comme `Require` est techniquement possible mais déconseillé. En effet, `mod_access_compat` 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.

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 :

### version 2.2 :

    Order deny,allow
    Deny from all

### version 2.4 :

    Require all denied

Dans cet exemple, il n'y a pas d'authentification et toutes les requêtes sont acceptées :

### version 2.2 :

    Order allow,deny
    Allow from all

### version 2.4 :

    Require all granted

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 :

### version 2.2 :

    Order Deny,Allow
    Deny from all
    Allow from example.org

### version 2.4 :

    Require host example.org

Dans l'exemple suivant, le mélange d'anciennes et de nouvelles directives produit des résultats inattendus.

### Mélange d'anciennes et de nouvelles directives : RESULTAT INATTENDU

    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

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 `mod_access_compat` sont prioritaires par rapport à celles de `mod_authz_host`.

L'exemple suivant quant à lui produit un résultat conforme :

### Mélange d'anciennes et de nouvelles directives : RESULTAT CONFORME

    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

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 `Satisfy` était définie à sa valeur par défaut ALL, les lignes de configuration qui désactivent le contrôle d'accès basé sur l'hôte sont maintenant omises :

### Version 2.2 :

    # 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

### Version 2.4 :

    # 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

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 :

### Version 2.2 :

    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

### Version 2.4 :

    AuthType Basic
    AuthBasicProvider file
    AuthUserFile /example.com/conf/users.passwd
    AuthName secure
    <RequireAll>
      Require valid-user
      Require ip 127.0.0.1
    </RequireAll>

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 :

### Version 2.2 :

    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

### Version 2.4 :

    AuthType Basic
    AuthBasicProvider file
    AuthUserFile /example.com/conf/users.passwd
    AuthName secure
    # Implicite : <RequireAny>
    Require valid-user
    Require ip 127.0.0.1

### Autres changements dans la configuration

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é.
- La directive `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é.
- La directive `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.
- La valeur par défaut de la directive `AllowOverride` est maintenant `None`.
- La valeur par défaut de la directive `EnableSendfile` est maintenant Off.
- La valeur par défaut de la directive `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.
- La directive `KeepAlive` n'accepte que les valeurs `On` ou `Off`. Avant, toute valeur autre que "Off" ou "0" était traitée comme "On".
- Les directives AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la directive unique `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`:
  - L'élément `#if expr` utilise maintenant le nouvel interpréteur d'expressions. L'ancienne syntaxe peut être réactivée via la directive `SSILegacyExprParser`.
  - 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.
- `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`
- Jusqu'à la version 2.2, sur les plateformes de style Unix, les commandes de redirection des logs définies via `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 logs

## Changements divers ¶

- `mod_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.
- La directive `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.
- Les pages d'erreur multilingues de la version 2.2.x ne fonctionneront qu'après avoir été corrigées pour respecter la nouvelle syntaxe de l'élément `#if expr=` du module `mod_include`, ou si la directive `SSILegacyExprParser` a été activée pour le répertoire contenant les pages d'erreur.
- La fonctionnalité fournie par `mod_authn_alias` dans les précédentes versions (en fait la directive `AuthnProviderAlias`) est maintenant fournie par `mod_authn_core`.
- `mod_cgid` utilise la valeur de la directive `Timeout` du serveur pour limiter le temps d'attente entre les sorties d'un programme CGI. La valeur de ce temps d'attente peut maintenant être modifiée via la directive `CGIDScriptTImeout`.
- Le symbole `<set>` de `mod_include` n’effectue plus le décodage d’entité sur la valeur définie.

## Modules tiers ¶

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.

## Problèmes de mise à jour courants ¶

- Erreurs au démarrage :
  - `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/httpd.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é.
- Erreurs de traitement des requêtes :
  - `configuration error: couldn't check user: /path` - chargez le module `mod_authn_core`.
  - Les fichiers `.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`.