Serveur Apache HTTP Version 2.2
Serveur Apache HTTP Version 2.2
Les directives des fichiers de configuration peuvent s'appliquer
au serveur dans son ensemble, ou seulement � des r�pertoires, fichiers, h�tes,
ou URLs particuliers. Ce document d�crit comment utiliser les conteneurs de
sections de configuration ou les fichiers .htaccess pour
modifier la port�e des directives de configuration.
| Modules Apparent�s | Directives Apparent�es |
|---|---|
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.1>
# les directives situ�es ici ne s'appliquent que si la version
# est sup�rieure ou �gale � 2.1.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.
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 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 Apache, 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 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.
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>
Order allow,deny
Deny from all
</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>
Order allow,deny
Deny from all
</Files>
</Directory>
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>
Order Allow,Deny
Deny from all
</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 d'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>
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)$>
Order allow,deny
Deny from all
</FilesMatch>
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/>
Order allow,deny
Deny from all
</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.
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.
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
va interdire l'utilisation du serveur proxy pour acc�der au site
cnn.com.
<Proxy http://cnn.com/*>
Order allow,deny
Deny from all
</Proxy>
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 :
AllowOverride
ne fonctionne que dans les sections
<Directory>.Options FollowSymLinks et
SymLinksIfOwnerMatch ne fonctionnent que dans les sections
<Directory> ou les fichiers
.htaccess.Options ne peut pas �tre
utilis�e dans les sections
<Files>
et <FilesMatch>.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 :
<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>)<DirectoryMatch>
(et <Directory ~>)<Files> et <FilesMatch> sont appliqu�es
simultan�ment<Location>
et <LocationMatch> sont appliqu�es
simultan�mentMises � part les sections <Directory>, chaque groupe est trait� selon
l'ordre dans lequel il appara�t dans les fichiers 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.
Les sections situ�es plus loin dans le fichier de configuration pr�valent sur celles qui les pr�c�dent.
<Location>/<LocationMatch>
est r�ellement trait�e juste avant la phase de traduction du nom
(o� Aliases et DocumentRoots
sont utilis�s pour faire correspondre les URLs aux noms de fichiers).
Les effets de cette s�quence disparaissent totalement lorsque
la traduction est termin�e.
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 />
Order deny,allow
Allow from all
</Location>
:if expand("%") == ""|browse confirm w|else|confirm w|endif
# Arrghs! Cette section <Directory> n'aura aucun effet
<Directory />
Order allow,deny
Allow from all
Deny from badguy.example.com
</Directory>