Serveur HTTP Apache Version 2.5

Les fichiers .htaccess fournissent une méthode pour
modifier la configuration du serveur au niveau de chaque répertoire, sans
modifier les fichiers de configuration principaux du serveur.
Fichiers .htaccess
Que sont ce fichiers, comment les utiliser ?
Quand doit-on (ne doit-on pas) utiliser
les fichiers .htaccess ?
Comment sont appliquées les directives ?
Exemple d'authentification
Exemple d'Inclusion Côté Serveur (Server Side
Includes - SSI)
Les règles de réécriture dans les fichiers .htaccess
Exemple de CGI
Résolution des problèmes| Modules Apparentés | Directives Apparentées |
|---|---|
Les fichiers .htaccess (ou "fichiers de
configuration distribués") fournissent une méthode pour modifier la
configuration du serveur au niveau d'un répertoire. Un fichier,
contenant une ou plusieurs directives de configuration, est placé
dans un répertoire de documents particulier, et ses directives
s'appliquent à ce répertoire et à tous ses sous-répertoires.
Si vous voulez donner un autre nom à votre fichier
.htaccess, vous pouvez le faire en utilisant la
directive AccessFileName. Par
exemple, si vous préférez nommer votre fichier
.config, vous pouvez mettre ceci dans le fichier de
configuration de votre serveur :
AccessFileName ".config"
Les directives dans les fichiers .htaccess utilisent la même
syntaxe que les fichiers de
configuration principaux. Ce que vous pouvez mettre dans ces
fichier est déterminé par les directives AllowOverride et AllowOverrideList. La directive AllowOverride spécifie,
sous forme de catégories, quelles directives seront traitées si
elles se trouvent dans un fichier .htaccess, alors que la
directive AllowOverrideList nomme individuellement les
directives permises (voir ci-après). Si une
directive est permise dans un fichier .htaccess,
la documentation de cette directive contiendra une section Override,
spécifiant quelle valeur doit prendre la directive AllowOverride pour que cette directive
soit traitée.
AllowOverride est None. Cela signifie
que les fichiers .htaccess seront complètement ignorés, à moins
que vous ne les autorisiez explicitement pour un répertoire.Par exemple, si vous regardez la documentation de la directive
AddDefaultCharset, vous verrez
que cette dernière est permise dans les fichiers
.htaccess (Voir la ligne de contexte dans le résumé de
la directive). La ligne Override indique
FileInfo. Vous devez donc avoir au moins
AllowOverride FileInfo pour que cette directive soit
traitée dans les fichiers .htaccess.
Si vous avez accès au fichier de configuration principal du serveur, il
est préférable d’y mettre toute votre configuration, plutôt que d’utiliser
des fichiers .htaccess. Cela concerne l’authentification de
l’utilisateur, les règles de mod_rewrite et tout ce que
vous seriez tenté de mettre dans un fichier .htaccess. Les
directives du fichier de configuration principal ne sont chargées qu’une
seule fois au démarrage du serveur et non pas à chaque requête, et en
particulier, mod_rewrite fonctionne mieux dans un contexte
de configuration globale du serveur.
Les fichiers .htaccess ne devraient être utilisés que dans
le cas où les fournisseurs de contenu ont besoin de modifier la
configuration du serveur au niveau d'un répertoire, mais ne possèdent pas
l'accès du superutilisateur sur le système du serveur. Cela est courant dans
les environnements d’hébergement géré, l’hébergement basé sur un panneau de
contrôle (comme cPanel ou Plesk) et les systèmes de gestion de contenu où
l’application fournit un fichier .htaccess avec sa
distribution. Si l’administrateur du serveur n’a pas envie d’effectuer des
changements de configuration incessants, il peut être intéressant de
permettre aux utilisateurs isolés d'effectuer eux-mêmes ces modifications
par le biais de fichiers .htaccess.
Il y a deux raisons de préférer le fichier de configuration principal
aux fichiers .htaccess : la performance et la sécurité.
Performance : Lorsque la directive
AllowOverride est définie de
façon à autoriser l'utilisation des fichiers .htaccess,
httpd va rechercher leur présence dans chaque répertoire. Ainsi,
permettre l'utilisation des fichiers .htaccess est déjà
en soi une cause de dégradation des performances, que vous utilisiez
effectivement ces fichiers ou non ! De plus, le fichier
.htaccess est chargé en mémoire chaque fois qu'un
document fait l'objet d'une requête.
Notez aussi que httpd doit rechercher les fichiers
.htaccess dans tous les répertoires de niveau
supérieur, afin de rassembler toutes les directives qui s'appliquent
au répertoire courant (Voir la section comment sont
appliquées les directives). Ainsi, si un fichier fait l'objet
d'une requête à partir d'un répertoire
/www/htdocs/exemple, httpd doit rechercher les
fichiers suivants :
/.htaccess /www/.htaccess /www/htdocs/.htaccess /www/htdocs/example/.htaccess
En conséquence, chaque accès à un fichier de ce répertoire
nécessite 4 accès au système de fichiers supplémentaires pour
rechercher des fichiers .htaccess, même si
aucun de ces fichiers n'est présent. Notez que cet exemple ne peut
se produire que si les fichiers .htaccess ont été
autorisés pour le répertoire /, ce qui est rarement le
cas.
Sécurité : Si vous permettez aux
utilisateurs de modifier la configuration du serveur, il peut en
résulter des conséquences sur lesquelles vous n'aurez aucun
contrôle. Réfléchissez bien avant de donner ce privilège à vos
utilisateurs. Notez aussi que ne pas donner aux utilisateurs les
privilèges dont ils ont besoin va entraîner une augmentation des
demandes de support technique. Assurez-vous d'avoir informé
clairement vos utilisateurs du niveau de privilèges que vous leur
avez attribué. Indiquer exactement comment vous avez défini la
directive AllowOverride et
diriger les utilisateurs vers la documentation correspondante vous
évitera bien des confusions ultérieures.
Si vous devez autoriser les fichiers .htaccess mais voulez
n’autoriser que l’utilisation de directives spécifiques au lieu de
catégories entières de directives, utilisez la directive AllowOverrideList. Cette dernière vous permet de
nommer individuellement les directives autorisées, vous permettant ainsi un
contrôle plus fin que dans le cas de la directive AllowOverride seule :
# N’autoriser que des directives spécifiques, pas des catégories entières de # directives AllowOverride None AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond
Avec cette configuration, toute directive non explicitement spécifiée
causera une erreur du serveur si elle est rencontrée dans un fichier
.htaccess. C’est un bon compromis entre possibilité et
impossibilité totales d’outrepasser la configuration globale.
Notez que mettre un fichier .htaccess contenant une
directive dans un répertoire /www/htdocs/exemple
revient exactement au même que mettre la même directive dans une
section Directory <Directory "/www/htdocs/exemple">
du fichier de configuration de votre serveur principal :
Fichier .htaccess dans
/www/htdocs/exemple :
/www/htdocs/exempleAddType text/example ".exm"
httpd.conf<Directory "/www/htdocs/example">
AddType text/example ".exm"
</Directory>
L'utilisation des fichiers .htaccess peut être
entièrement désactivée en définissant la directive AllowOverride à none :
AllowOverride None
Les directives de configuration situées dans un fichier
.htaccess s'appliquent au répertoire dans lequel ce
fichier .htaccess se trouve, ainsi qu'à tous ses
sous-répertoires. Cependant, il est important de garder à l'esprit
qu'il peut y avoir des fichiers .htaccess dans les
répertoires de niveau supérieur. Les directives sont appliquées
selon l'ordre dans lequel elles sont rencontrées. Ainsi, les
directives d'un fichier .htaccess situé dans un
répertoire particulier peuvent écraser les directives se trouvant
dans des fichiers .htaccess situés à un niveau
supérieur dans l'arborescence des répertoires. Et ces dernières
peuvent elles-mêmes avoir écrasé des directives d'un fichier
.htaccess situé à un niveau encore plus haut, ou dans
le fichier de configuration du serveur principal.
Exemple :
Dans le répertoire /www/htdocs/exemple1 se trouve un
fichier .htaccess contenant ce qui suit :
Options +ExecCGI
Note : "AllowOverride Options" doit être présent
pour permettre l'utilisation de la directive "Options" dans les fichiers
.htaccess.
Dans le répertoire /www/htdocs/exemple1/exemple2 se
trouve un fichier .htaccess contenant ce qui suit
:
Options Includes
Ainsi, à cause de ce second fichier .htaccess du
répertoire /www/htdocs/exemple1/exemple2, l'exécution
des CGI est interdite, car la dernière définition d'options
Options Includes écrase toute autre définition
d'options d'un fichier .htaccess situé dans un
répertoire de niveau supérieur.
Comme indiqué dans la documentation sur les Sections de configuration, les fichiers
.htaccess peuvent écraser les directives des sections
<Directory> pour
le répertoire correspondant, mais peuvent eux-mêmes être écrasés
par d'autres types de sections des fichiers de la
configuration principale. Cette possibilité peut s'avérer utile pour
forcer certaines configurations, même en cas de présence de l'option
libérale AllowOverride. Par
exemple, pour interdire l'exécution de scripts en autorisant la
définition de toute autre option dans les fichiers
.htaccess, vous pouvez utiliser :
<Directory "/www/htdocs">
AllowOverride All
</Directory>
<Location "/">
Options +IncludesNoExec -ExecCGI
</Location>
DocumentRoot est
/www/htdocs.Comme avec toute utilisation de fichier .htaccess, placer
ces directives dans une section <Directory> est préférable si vous avez accès au
fichier de configuration principal (voir ci-avant).
L’exemple suivant montre l’approche .htaccess :
Contenu du fichier .htaccess :
AuthType Basic AuthName "Password Required" AuthUserFile "/www/passwords/password.file" AuthGroupFile "/www/passwords/group.file" Require group admins
Notez que AllowOverride AuthConfig doit être présent
pour que ces directives produisent leur effet.
Vous pouvez vous référer au tutoriel sur l'authentification pour une description plus détaillée de l'authentification et de l'autorisation.
Les fichiers .htaccess sont aussi utilisés pour activer les
SSI (Server Side Includes) pour un répertoire particulier. Pour y parvenir,
on utilise les directives de configuration suivantes, placées dans un
fichier .htaccess enregistré dans le répertoire considéré :
Options +Includes AddType text/html "shtml" AddHandler server-parsed shtml
Notez que AllowOverride Options et AllowOverride
FileInfo doivent être tous les deux présents pour que ces
directives puissent produire leur effet.
Vous pouvez vous référer au tutoriel SSI pour une description plus détaillée des SSI.
Sivous utilisez des directives RewriteRule dans un fichier
.htaccess, gardez à l'esprit que les choses sont légèrement
différentes dans un contexte de répertoire. En particulier, les règles
sont relatives au répertoire courant, et non à l'URI original. Considérez
les exemples suivants :
# Dans httpd.conf RewriteRule "^/images/(.+)\.jpg" "/images/$1.png" # Dans un fichier .htaccess situé dans le répertoire racine de vos # documents RewriteRule "^images/(.+)\.jpg" "images/$1.png" # Dans un fichier .htaccess situé dans le répertoire images/ RewriteRule "^(.+)\.jpg" "$1.png"
On voit que si le fichier .htaccess se situe à la racine
de vos documents, le slash de tête est supprimé de la valeur de
remplacement spécifiée pour la règle RewriteRule, et que si le fichier
.htaccess se situe dans le répertoire images,
la chaîne /images/ disparaît de cette même valeur de
remplacement. Il doit donc en être de même dans votre expression
rationnelle.
Notez aussi que dans un contexte .htaccess, les expressions
rationnelles sont recompilées à chaque requête, alors que dans un contexte de
configuration principale, elle ne sont compilées qu’une seule fois et mises en
cache.
Veuillez vous référer à cette documentation
pour une étude détaillée de l'utilisation du module
mod_rewrite.
mod_proxy_fcgi avec un serveur d’applications FastCGI ou un
gestionnaire spécifique à un cadriciel. Les informations ci-après restent
cependant valables pour les environnements qui reposent encore sur une CGI
traditionnelle.Vous pouvez utiliser un fichier .htaccess pour autoriser
l’exécution de programmes CGI dans un répertoire particulier. Pour y
parvenir, vous pouvez utiliser la configuration suivante :
Options +ExecCGI AddHandler cgi-script "cgi" "py"
Alternativement, si vous souhaitez que tous les fichiers d'un répertoire donné soient considérés comme des programmes CGI, vous pouvez utiliser la configuration suivante :
Options +ExecCGI SetHandler cgi-script
Notez que AllowOverride Options et AllowOverride
FileInfo doivent être tous les deux présents pour que ces
directives puissent produire leur effet.
Vous pouvez vous référer au tutoriel CGI pour une description plus détaillée de la configuration et de la proprammation CGI.
De nombreuses raisons peuvent être à l'origine du fait que
les directives que vous avez mises dans un fichier
.htaccess ne produisent pas l'effet désiré.
Le plus souvent, le problème vient du fait que la définition de la
directive AllowOverride ne permet pas
l'activation des directives de votre fichier .htaccess.
Vérifiez si une directive AllowOverride None n'affecte pas le
répertoire où se trouve votre fichier. Un bon test consiste à mettre un mot
dénué de sens dans votre ficher .htaccess et de recharger la
page :
TestMe
Si aucune erreur (HTTP 500) n'est générée par le
serveur, il est pratiquement certain qu'une directive
AllowOverride None affecte votre répertoire.
Par contre, si vous obtenez des erreurs de serveur lorsque vous
tentez d'accéder à des documents, consultez votre journal des
erreurs de httpd. Il vous indiquera probablement que la directive
utilisée dans votre fichier .htaccess n'est pas
permise.
[Tue May 06 09:12:31.528374 2025] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: DirectoryIndex not allowed here
Cela signifie soit que vous utilisez une directive qui n'est
jamais permise dans les fichiers .htaccess, soit
que vous n'avez tout simplement pas défini la directive
AllowOverride à un niveau
suffisant pour la directive que vous utilisez. Consultez la
documentation de cette directive pour déterminer quel cas
s'applique.
Le journal des erreurs peut aussi vous signaler une erreur de syntaxe dans l'usage de la directive elle-même.
[Tue May 06 09:14:02.946218 2025] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
Dans ce cas, le message d'erreur sera spécifique à l'erreur de syntaxe que vous avez commise.