Sections de configuration

Types de conteneurs de sections de configuration

Il existe deux grands types de conteneurs. La plupart des conteneurs sont �valu�s pour chaque requ�te. Les directives qu'ils contiennent s'appliquent seulement aux requ�tes qui sont concern�es par le conteneur. En revanche, les conteneurs <IfDefine>, <IfModule>, et <IfVersion> sont �valu�s seulement au d�marrage et au red�marrage du serveur. Si leurs conditions sont v�rifi�es au d�marrage, les directives qu'ils contiennent s'appliqueront � toutes les requ�tes. Si leurs conditions ne sont pas v�rifi�es, les directives qu'ils contiennent seront ignor�es.

Le conteneur <IfDefine> contient des directives qui ne seront appliqu�es que si un param�tre appropri� a �t� d�fini dans la ligne de commande de httpd. Par exemple, avec la configuration suivante, toutes les requ�tes seront redirig�es vers un autre site si le serveur est d�marr� en utilisant la ligne de commande : httpd -DClosedForNow:

<IfDefine ClosedForNow>
    Redirect "/" "http://otherserver.example.com/"
</IfDefine>

Le conteneur <IfModule> est similaire; les directives qu'il contient ne s'appliqueront que si un module particulier est disponible au niveau du serveur. Le module doit �tre soit compil� statiquement dans le serveur, soit dynamiquement et dans ce cas, la ligne LoadModule correspondante doit appara�tre plus haut dans le fichier de configuration. Ce conteneur ne doit �tre utilis� que dans le cas o� votre fichier de configuration doit fonctionner ind�pendamment de la pr�sence ou de l'absence de certains modules. Il ne doit pas contenir de directives que vous souhaitez voir s'appliquer syst�matiquement, car vous pouvez perdre ainsi de pr�cieux messages d'erreur � propos de modules manquants.

Dans l'exemple suivant, la directive MimeMagicFile ne s'appliquera que si le module mod_mime_magic est disponible.

<IfModule mod_mime_magic.c>
    MimeMagicFile "conf/magic"
</IfModule>

Le conteneur <IfVersion> est similaire aux conteneurs <IfDefine> et <IfModule>; les directives qu'il contient ne s'appliqueront que si une version particuli�re du serveur s'ex�cute. Ce conteneur a �t� con�u pour une utilisation dans les suites de tests et les grands r�seaux qui doivent prendre en compte diff�rentes versions et configurations de httpd.

<IfVersion >= 2.4>
    # les directives situ�es ici ne s'appliquent que si la version 

    # est sup�rieure ou �gale � 2.4.0.
</IfVersion>

<IfDefine>, <IfModule>, et <IfVersion> peuvent inverser leur test conditionnel en le faisant pr�c�der d'un "!". De plus, ces sections peuvent �tre imbriqu�es afin de d�finir des restrictions plus complexes.

Syst�me de fichiers, arborescence du site web et expressions bool�ennes

Les conteneurs de sections de configuration les plus couramment utilis�s sont ceux qui modifient la configuration de points particuliers du syst�me de fichiers ou de l'arborescence du site web. Tout d'abord, il est important de comprendre la diff�rence entre les deux. Le syst�me de fichiers est une vue de vos disques tels qu'ils sont per�us par votre syst�me d'exploitation. Par exemple, avec une installation par d�faut, Apache httpd est situ� dans /usr/local/apache2 pour le syst�me de fichiers UNIX, ou "c:/Program Files/Apache Group/Apache2" pour le syst�me de fichiers Windows. (Notez que des slashes directs doivent toujours �tre utilis�s comme s�parateur de chemin dans les fichiers de configuration d'Apache httpd, m�me sous Windows.) Quant � l'arborescence du site web, il s'agit d'une vue de votre site tel que pr�sent� par le serveur web et per�ue par le client. Ainsi le chemin /dir/ dans l'arborescence du site web correspond au chemin /usr/local/apache2/htdocs/dir/ dans le syst�me de fichiers pour une installation d'Apache httpd par d�faut sous UNIX. En outre, l'arborescence du site web n'a pas besoin de correspondre en permanence au syst�me de fichiers, car les pages web peuvent �tre g�n�r�es dynamiquement � partir de bases de donn�es ou d'autres emplacements.

Conteneurs de syst�me de fichiers

Les conteneurs <Directory> et <Files>, ainsi que leurs �quivalents acceptant les expressions rationnelles, appliquent des directives � certaines parties du syst�me de fichiers. Les directives contenues dans une section <Directory> s'appliquent au r�pertoire pr�cis�, ainsi qu'� tous ses sous-r�pertoires et aux fichiers que ces derniers contiennent. Le m�me effet peut �tre obtenu en utilisant les fichiers .htaccess. Par exemple, avec la configuration suivante, l'indexation sera activ�e pour le r�pertoire /var/web/dir1 et tous ses sous-r�pertoires.

<Directory "/var/web/dir1">
    Options +Indexes
</Directory>

Les directives contenues dans une section <Files> s'appliquent � tout fichier avec le nom sp�cifi�, quel que soit le r�pertoire dans lequel il se trouve. Ainsi par exemple, les directives de configuration suivantes, si elles sont plac�es dans la section principale du fichier de configuration, vont interdire l'acc�s � tout fichier nomm� private.html quel que soit l'endroit o� il se trouve.

<Files "private.html">
    Require all denied
</Files>

Pour faire r�f�rence � des fichiers qui se trouvent en des points particuliers du syst�me de fichiers, les sections <Files> et <Directory> peuvent �tre combin�es. Par exemple, la configuration suivante va interdire l'acc�s � /var/web/dir1/private.html, /var/web/dir1/subdir2/private.html, /var/web/dir1/subdir3/private.html, ainsi que toute instance de private.html qui se trouve dans l'arborescence /var/web/dir1/.

<Directory "/var/web/dir1">
    <Files "private.html">
        Require all denied
    </Files>
</Directory>

Conteneurs de l'arborescence du site web

le conteneur <Location> et son �quivalent acceptant les expressions rationnelles, modifient quant � eux la configuration de parties de l'arborescence du site web. Par exemple, la configuration suivante interdit l'acc�s � toute URL dont la partie chemin commence par /private. En particulier, l'interdiction s'appliquera aux requ�tes pour : http://yoursite.example.com/private, http://yoursite.example.com/private123, et http://yoursite.example.com/private/dir/file.html ainsi qu'� toute requ�te commen�ant par la cha�ne de caract�res /private.

<LocationMatch "^/private">
    Require all denied
</LocationMatch>

Le conteneur <Location> n'a pas besoin de faire r�f�rence � un �l�ment du syst�me de fichiers. Par exemple, l'exemple suivant montre comment faire r�f�rence � une URL particuli�re vers un gestionnaire interne du serveur HTTP Apache fourni par le module mod_status. Il n'est pas n�cessaire de trouver un fichier nomm� server-status dans le syst�me de fichiers.

<Location "/server-status">
    SetHandler server-status
</Location>

Espace web imbriqu�

Pour contr�ler deux URLs imbriqu�es, on doit tenir compte de l'ordre dans lequel certaines sections ou directives sont �valu�es. Pour <Location>, on doit avoir :

<Location "/foo">
</Location>
<Location "/foo/bar">
</Location>

Les directives <Alias>, quant � elles, sont �valu�es vice-versa :

Alias "/foo/bar" "/srv/www/uncommon/bar"
Alias "/foo" "/srv/www/common/foo"

Ceci est aussi vrai pour les directives ProxyPass :

ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On

Caract�res de remplacement et expressions rationnelles

Les conteneurs <Directory>, <Files>, et <Location> peuvent utiliser des caract�res de remplacement de style shell comme dans la fonction fnmatch de la biblioth�que C standard. Le caract�re "*" correspond � toute s�quence de caract�res, "?" � un caract�re seul, et "[seq]" � tout caract�re contenu dans seq. Le caract�re "/" ne peut pas faire l'objet d'un remplacement; il doit �tre sp�cifi� explicitement.

Si une d�finition des crit�res de correspondance encore plus souple est n�cessaire, chaque conteneur poss�de son �quivalent acceptant les expressions rationnelles : <DirectoryMatch>, <FilesMatch>, et <LocationMatch> acceptent les expressions rationnelles compatibles Perl pour d�finir les crit�res de correspondance. Mais voyez plus loin la section � propos de la combinaison des sections de configuration pour comprendre comment l'utilisation de conteneurs avec des expressions rationnelles va modifier la mani�re dont les directives sont appliqu�es.

Un conteneur qui modifie la configuration de tous les r�pertoires utilisateurs � l'aide de caract�res de remplacement mais sans utiliser les expressions rationnelles pourrait ressembler � ceci :

<Directory "/home/*/public_html">
    Options Indexes
</Directory>

Avec les conteneurs utilisant les expressions rationnelles, on peut interdire l'acc�s � de nombreux types de fichiers d'images simultan�ment :

+<FilesMatch "\.(?i:gif|jpe?g|png)$">
    Require all denied
</FilesMatch>

Les expressions rationnelles contenant des groupes nomm�s et des r�f�rences arri�res sont ajout�es � l'environnement avec leur nom en majuscules. Ceci permet de r�f�rencer des �l�ments de chemins de fichiers et d'URLs depuis une expression et au sein de modules comme mod_rewrite.

<DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)">
    require ldap-group "cn=%{env:MATCH_SITENAME},ou=combined,o=Example"
</DirectoryMatch>

Expressions bool�ennes

La directive <If> permet de modifier la configuration en fonction d'une condition qui peut �tre d�finie sous la forme d'une expression bool�enne. Dans l'exemple suivant, l'acc�s est interdit si l'en-t�te HTTP Referer ne commence pas par "http://www.example.com/".

<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
    Require all denied
</If>

Que faut-il utiliser et quand ?

Choisir entre des conteneurs de syst�me de fichiers et des conteneurs d'arborescence du site web est vraiment tr�s simple. Pour appliquer des directives � des objets qui r�sident dans le syst�me de fichiers, utilisez toujours un conteneur <Directory> ou <Files>. Pour appliquer des directives � des objets qui ne r�sident pas dans le syst�me de fichiers (comme une page web g�n�r�e par une base de donn�es), utilisez un conteneur <Location>.

Il ne faut jamais utiliser un conteneur <Location> pour restreindre l'acc�s � des objets du syst�me de fichiers, car plusieurs localisations de l'arborescence du site web (URLs) peuvent correspondre � la m�me localisation du syst�me de fichier, ce qui peut permettre de contourner vos restrictions. Par exemple, imaginez la configuration suivante :

<Location "/dir/">
    Require all denied
</Location>

Elle fonctionne correctement si la requ�te appelle http://yoursite.example.com/dir/. Mais que va-t-il se passer si votre syst�me de fichiers est insensible � la casse ? Votre restriction va pouvoir �tre tout simplement contourn�e en envoyant une requ�te sur http://yoursite.example.com/DIR/. Le conteneur <Directory>, quant � lui, s'appliquera � tout contenu servi � partir de cette localisation, sans tenir compte de la mani�re dont il est appel�. (Les liens du syst�me de fichiers constituent une exception. Le m�me r�pertoire peut �tre plac� dans plusieurs parties du syst�me de fichiers en utilisant des liens symboliques. Le conteneur <Directory> va suivre le lien symbolique sans modifier le nom du chemin. Par cons�quent, pour plus de s�curit�, les liens symboliques doivent �tre d�sactiv�s � l'aide de la directive Options appropri�e.)

Si vous pensez que vous n'�tes pas concern� par ce probl�me parceque vous utilisez un syst�me de fichiers sensible � la casse, gardez � l'esprit qu'il y a de nombreuses autres mani�res pour faire correspondre plusieurs localisations de l'arborescence du site web � la m�me localisation du syst�me de fichiers. C'est pourquoi vous devez autant que possible toujours utiliser les conteneurs de syst�me de fichiers. Il y a cependant une exception � cette r�gle. Placer des restrictions de configuration dans un conteneur <Location "/"> est tout � fait sans rique car ce conteneur va s'appliquer � toutes les requ�tes sans tenir compte de l'URL sp�cifique.

Imbrication des sections

Certains types de sections peuvent �tre imbriqu�s : d'une part, on peut utiliser les sections <Files> � l'int�rieur des sections <Directory>, d'autre part, on peut utiliser les directives <If> � l'int�rieur des sections <Directory>, <Location> et <Files> (mais pas � l'int�rieur d'une autre section <If>). Les valeurs des expressions rationnelles correspondant aux sections nomm�es se comportent de mani�re identique.

Les sections imbriqu�es sont fusionn�es apr�s les sections non-imbriqu�es de m�me type.

H�tes virtuels

Le conteneur <VirtualHost> contient des directives qui s'appliquent � des h�tes sp�cifiques. Ceci s'av�re utile pour servir des h�tes multiples � partir de la m�me machine, chacun d'entre eux poss�dant une configuration diff�rente. Pour de plus amples informations, voir la Documentation sur les h�tes virtuels.

Mandataire

Les conteneurs <Proxy> et <ProxyMatch> appliquent les directives de configuration qu'ils contiennent uniquement aux sites qui correspondent � l'URL sp�cifi�e et auxquels on a acc�d� via le serveur mandataire du module mod_proxy. Par exemple, la configuration suivante n'autorisera qu'un sous-ensemble de clients � acc�der au site www.example.com en passant par le serveur mandataire :

<Proxy "http://www.example.com/*">
    Require host yournetwork.example.com
</Proxy>

Quelles sont les directives autoris�es ?

Pour d�terminer quelles sont les directives autoris�es pour tel type de section de configuration, v�rifiez le Contexte de la directive. Tout ce qui est autoris� dans les sections <Directory> l'est aussi d'un point de vue syntaxique dans les sections <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, <LocationMatch>, <Proxy>, et <ProxyMatch>. Il y a cependant quelques exceptions :

• La directive AllowOverride ne fonctionne que dans les sections <Directory>.
• Les Options FollowSymLinks et SymLinksIfOwnerMatch ne fonctionnent que dans les sections <Directory> ou les fichiers .htaccess.
• La directive Options ne peut pas �tre utilis�e dans les sections <Files> et <FilesMatch>.

Comment les sections sont combin�es entre elles

Les sections de configuration sont appliqu�es dans un ordre tr�s particulier. Il est important de savoir comment cet ordre est d�fini car il peut avoir des effets importants sur la mani�re dont les directives de configuration sont interpr�t�es.

L'ordre dans lequel les sections sont combin�es est :

1. Les sections <Directory> (� l'exception des expressions rationnelles) et les fichiers .htaccess sont appliqu�s simultan�ment (avec la possibilit� pour .htaccess, s'il y est autoris�, de pr�valoir sur <Directory>)
2. Les sections <DirectoryMatch> (et <Directory "~">)
3. Les sections <Files> et <FilesMatch> sont appliqu�es simultan�ment
4. Les sections <Location> et <LocationMatch> sont appliqu�es simultan�ment
5. Les directives <If>

Quelques remarques importantes :

• Mises � part les sections <Directory>, dans chaque groupe, les sections sont trait�es selon l'ordre dans lequel elles apparaissent dans les fichiers de configuration. Par exemple, une requ�te pour /foo correspondra � <Location "/foo/bar"> et <Location "/foo"> (dans ce cas le groupe 4) : les deux sections seront �valu�es mais selon l'ordre dans lequel elles apparaissent dans le fichier de configuration..
• Les sections <Directory> (groupe 1 ci-dessus) sont trait�es dans l'ordre du r�pertoire le plus court vers le plus long. Par exemple, <Directory "/var/web/dir"> sera trait� avant <Directory "/var/web/dir/subdir">.
• Si plusieurs sections <Directory> s'appliquent au m�me r�pertoire, elles sont trait�es selon l'ordre dans lequel elles apparaissent dans le fichier de configuration.
• Les sections de configuration incluses via la directive Include sont trait�es comme si elles se trouvaient r�ellement dans le fichier qui les inclut � la position de la directive Include.
• Les sections situ�es � l'int�rieur de sections <VirtualHost> sont appliqu�es apr�s les sections correspondantes situ�es en dehors de la d�finition de l'h�te virtuel, ce qui permet � l'h�te virtuel de pr�valoir sur la configuration du serveur principal.
• Quand la requ�te est servie par le module mod_proxy, le conteneur <Proxy> prend la place du conteneur <Directory> dans l'ordre de traitement.

Interactions entre modules et sections de configuration

Une question se pose souvent apr�s avoir lu comment les sections de configuration sont fusionn�es : comment et quand les directives de modules particuliers comme mod_rewrite sont-elles interpr�t�es ? La r�ponse n'est pas triviale et n�cessite un approfondissement. Chaque module httpd g�re sa propre configuration, et chacune de ses directives dans apache2.conf d�finit un �l�ment de configuration dans un contexte particulier. httpd n'ex�cute pas un commande au moment o� elle est lue.

A l'ex�cution, le noyau de httpd parcours les sections de configuration dans l'ordre d�crit ci-dessus afin de d�terminer lesquelles s'appliquent � la requ�te courante. Lorsqu'une premi�re section s'applique, elle est consid�r�e comme la configuration courante pour cette requ�te. Si une section suivante s'applique aussi, chaque module qui poss�de des directives dans chacune de ces sections a la possibilit� de fusionner sa configuration entre ces deux sections. Il en r�sulte une troisi�me configuration et le processus de fusion se poursuit jusqu'� ce que toutes les sections de configuration aient �t� �valu�es.

Apr�s l'�tape pr�c�dente, le traitement proprement dit de la requ�te HTTP peut commencer : chaque module peut effectuer toute t�che qui lui incombe, et pour d�terminer de quelle mani�re dont il doit agir, il peut s'appuyer sur le noyau de httpd pour retrouver sa configuration globale issue de la fusion pr�c�dente.

Un exemple permet de mieux visualiser l'ensemble du processus. la configuration suivante utilise la directive Header du module mod_headers pour d�finir un en-t�te HTTP sp�cifique. Quelle valeur httpd va-t-il affecter � l'en-t�te CustomHeaderName pour une requ�te vers /example/index.html ?

<Directory "/">
    Header set CustomHeaderName one
    <FilesMatch ".*">
        Header set CustomHeaderName three
    </FilesMatch>
</Directory>
<Directory "/example">
    Header set CustomHeaderName two
</Directory>

• Directory "/" s'applique, et une configuration initiale est cr��e qui d�finit l'en-t�te CustomHeaderName avec la valeur one.
• Directory "/example" s'applique, et comme mod_headers sp�cifie dans son code que la valeur d'un en-t�te doit �tre �cras�e si ce dernier est d�fini � nouveau, une nouvelle configuration est cr��e qui d�finit l'en-t�te CustomHeaderName avec la valeur two.
• FilesMatch ".*" s'applique, une nouvelle opportunit� de fusion surgit, et l'en-t�te CustomHeaderName est d�fini � la valeur three.
• Finalement, au cours des �tapes suivantes du traitement de la requ�te HTTP, mod_headers sera sollicit�, et il se basera sur la configuration qui a d�fini l'en-t�te CustomHeaderName � la valeur three. mod_headers utilise normalement cette configuration pour accomplir sa t�che, � savoir d�finir des en-t�tes HTTP. Cela ne veut cependant pas dire qu'un module ne peut pas effectuer des actions plus complexes comme d�sactiver des directives car elle ne sont pas n�cessaires ou obsol�tes, etc...

Ceci est aussi vrai pour les fichiers .htaccess car ils poss�dent la m�me priorit� que les sections Directory dans l'ordre de fusion. Il faut bien comprendre que les sections de configuration comme Directory et FilesMatch ne sont pas comparables avec les directives sp�cifiques de modules comme Header ou RewriteRule car elles agissent � des niveaux diff�rents.

Quelques exemples utiles

Voici un exemple imaginaire qui montre l'ordre de combinaison des sections. En supposant qu'elles s'appliquent toutes � la requ�te, les directives de cet exemple seront appliqu�es dans l'ordre suivant : A > B > C > D > E.

<Location "/">
    E
</Location>
<Files "f.html">
    D
</Files>
<VirtualHost *>
<Directory "/a/b">
    B
</Directory>
</VirtualHost>
<DirectoryMatch "^.*b$">
    C
</DirectoryMatch>
<Directory "/a/b">
    A
</Directory>

Pour un exemple plus concret, consid�rez ce qui suit. Sans tenir compte de toute restriction d'acc�s plac�e dans les sections <Directory>, la section <Location> sera �valu�e en dernier et permettra un acc�s au serveur sans aucune restriction. En d'autres termes, l'ordre de la combinaison des sections est important, soyez donc prudent !

<Location "/">
    Require all granted
</Location>
# Arrghs!  Cette section <Directory> n'aura aucun effet
<Directory "/">
    <RequireAll>
        Require all granted
        Require not host badguy.example.com
    </RequireAll>
</Directory>