<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1741842:1934247 (outdated) -->
+<!-- English Revision: 1934247 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<summary>
<p>Les fichiers <code>.htaccess</code> fournissent une méthode pour
-modifier la configuration du serveur au niveau de chaque répertoire.</p>
+modifier la configuration du serveur au niveau de chaque répertoire, sans
+modifier les fichiers de configuration principaux du serveur.</p>
</summary>
<section id="related"><title>Fichiers .htaccess</title>
<module>core</module>
<module>mod_authn_file</module>
<module>mod_authz_groupfile</module>
- <module>mod_cgi</module>
<module>mod_include</module>
<module>mod_mime</module>
+ <module>mod_rewrite</module>
</modulelist>
<directivelist>
<directive module="core">AccessFileName</directive>
<directive module="core">AllowOverride</directive>
+ <directive module="core">AllowOverrideList</directive>
<directive module="core">Options</directive>
<directive module="mod_mime">AddHandler</directive>
<directive module="core">SetHandler</directive>
</directivelist>
</related>
- <note>Les fichiers <code>.htaccess</code> ne doivent être utilisés
- que si vous n'avez pas accès au fichier de configuration du serveur
- principal. L'utilisation des fichiers <code>.htaccess</code>
- ralentit le fonctionnement de votre serveur HTTP Apache. Il est toujours
- préférable de définir les directives que vous pouvez inclure dans un
- fichier <code>.htaccess</code> dans une section <directive
- module="core">Directory</directive>, car elles produiront le
- même effet avec de meilleures performances.</note>
+
</section>
<section id="what">
</highlight>
</note>
- <p>En général, les fichiers <code>.htaccess</code> utilisent la même
+ <p>Les directives dans les fichiers <code>.htaccess</code> utilisent la même
syntaxe que les <a href="../configuring.html#syntax">fichiers de
configuration principaux</a>. Ce que vous pouvez mettre dans ces
- fichier est déterminé par la directive <directive
- module="core">AllowOverride</directive>. Cette directive spécifie,
+ fichier est déterminé par les directives <directive
+ module="core">AllowOverride</directive> et <directive
+ module="core">AllowOverrideList</directive>. La directive <directive
+ module="core">AllowOverride</directive> spécifie,
sous forme de catégories, quelles directives seront traitées si
- elles se trouvent dans un fichier <code>.htaccess</code>. Si une
- directive est permise dans un fichier <code>.htaccess</code> file,
+ elles se trouvent dans un fichier <code>.htaccess</code>, alors que la
+ directive <directive
+ module="core">AllowOverrideList</directive> nomme individuellement les
+ directives permises (voir <a href="#when">ci-après</a>). Si une
+ directive est permise dans un fichier <code>.htaccess</code>,
la documentation de cette directive contiendra une section Override,
- spécifiant quelle valeur doit prendre <directive
+ spécifiant quelle valeur doit prendre la directive <directive
module="core">AllowOverride</directive> pour que cette directive
soit traitée.</p>
+ <note>La valeur par défaut de la directive <directive
+ module="core">AllowOverride</directive> est <code>None</code>. Cela signifie
+ que les fichiers <code>.htaccess</code> seront complètement ignorés, à moins
+ que vous ne les autorisiez explicitement pour un répertoire.</note>
+
<p>Par exemple, si vous regardez la documentation de la directive
<directive module="core">AddDefaultCharset</directive>, vous verrez
que cette dernière est permise dans les fichiers
<code>AllowOverride FileInfo</code> pour que cette directive soit
traitée dans les fichiers <code>.htaccess</code>.</p>
- <example><title>Exemple :</title>
- <table>
- <tr>
- <td><a
- href="../mod/directive-dict.html#Context">Contexte :</a></td>
- <td>configuration du serveur, serveur virtuel, directory, .htaccess</td>
- </tr>
-
- <tr>
- <td><a
- href="../mod/directive-dict.html#Override">Override:</a></td>
- <td>FileInfo</td>
- </tr>
- </table>
- </example>
-
- <p>Si vous n'êtes pas sûr qu'une directive particulière soit permise
- dans un fichier <code>.htaccess</code>, lisez la documentation de
- cette directive, et consultez la ligne de contexte pour
- ".htaccess".</p>
</section>
<section id="when"><title>Quand doit-on (ne doit-on pas) utiliser
les fichiers .htaccess ?</title>
- <p>En principe, vous ne devriez utiliser les fichiers
- <code>.htaccess</code> que lorsque vous n'avez pas accès au fichier de
- configuration du serveur principal. Par exemple, la fausse
- idée
- selon laquelle l'authentification de l'utilisateur devrait toujours
- être faite dans les fichiers <code>.htaccess</code> est très
- répandue. Il est aussi souvent avancé, ces dernières
- années, que les directives de <module>mod_rewrite</module> doivent
- être définies dans les fichiers <code>.htaccess</code>. Ceci est
- tout simplement faux. Vous pouvez configurer
- l'authentification des utilisateurs au niveau de la configuration du
- serveur principal, et c'est en fait cette méthode qui doit être
- privilégiée. De même, les directives de
- <code>mod_rewrite</code> fonctionneront mieux, à de nombreux égards,
- dans le contexte du serveur principal.</p>
-
- <p>Les fichiers <code>.htaccess</code> 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 root sur le système du serveur. Si
- l'administrateur du serveur ne souhaite pas effectuer des
- modifications de configuration incessantes, il peut être intéressant
- de permettre aux utilisateurs isolés d'effectuer eux-mêmes ces
- modifications par le biais de fichiers <code>.htaccess</code>. Ceci
- est particulièrement vrai dans le cas où le fournisseur d'accès à
- Internet héberge de nombreux sites d'utilisateurs sur un seul
- serveur, et souhaite que ces utilisateurs puissent modifier
- eux-mêmes leurs configurations.</p>
-
- <p>Cependant et d'une manière générale, il vaut mieux éviter
- d'utiliser les fichiers <code>.htaccess</code>. Tout élément de
- configuration que vous pourriez vouloir mettre dans un fichier
- <code>.htaccess</code>, peut aussi être mis, et avec la même
- efficacité, dans une section <directive module="core"
- type="section">Directory</directive> du fichier de configuration de
- votre serveur principal.</p>
-
- <p>Il y a deux raisons principales d'éviter l'utilisation des
- fichiers <code>.htaccess</code>.</p>
-
- <p>La première est liée aux performances. Lorsque la directive
+ <p>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 <code>.htaccess</code>. Cela concerne l’authentification de
+ l’utilisateur, les règles de <module>mod_rewrite</module> et tout ce que
+ vous seriez tenté de mettre dans un fichier <code>.htaccess</code>. 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, <module>mod_rewrite</module> fonctionne mieux dans un contexte
+ de configuration globale du serveur.</p>
+
+ <p>Les fichiers <code>.htaccess</code> 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 <code>.htaccess</code> 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 <code>.htaccess</code>.</p>
+
+ <p>Il y a deux raisons de préférer le fichier de configuration principal
+ aux fichiers <code>.htaccess</code> : la performance et la sécurité.</p>
+
+ <p><strong>Performance :</strong> Lorsque la directive
<directive module="core">AllowOverride</directive> est définie de
façon à autoriser l'utilisation des fichiers <code>.htaccess</code>,
httpd va rechercher leur présence dans chaque répertoire. Ainsi,
<code>/www/htdocs/exemple</code>, httpd doit rechercher les
fichiers suivants :</p>
- <example>
- /.htaccess<br />
- /www/.htaccess<br />
- /www/htdocs/.htaccess<br />
- /www/htdocs/exemple/.htaccess
- </example>
+ <highlight language="config">
+/.htaccess
+/www/.htaccess
+/www/htdocs/.htaccess
+/www/htdocs/example/.htaccess
+ </highlight>
<p>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
autorisés pour le répertoire <code>/</code>, ce qui est rarement le
cas.</p>
- <p>La seconde raison d'éviter l'utilisation des fichiers
- <code>.htaccess</code> est liée à la sécurité. Si vous permettez aux
+ <p><strong>Sécurité :</strong> 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
diriger les utilisateurs vers la documentation correspondante vous
évitera bien des confusions ultérieures.</p>
+ <p>Si vous devez autoriser les fichiers <code>.htaccess</code> mais voulez
+ n’autoriser que l’utilisation de directives spécifiques au lieu de
+ catégories entières de directives, utilisez la directive <directive
+ module="core">AllowOverrideList</directive>. 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 <directive
+ module="core">AllowOverride</directive> seule :</p>
+
+ <highlight language="config">
+# N’autoriser que des directives spécifiques, pas des catégories entières de
+# directives
+AllowOverride None
+AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond
+ </highlight>
+
+ <p>Avec cette configuration, toute directive non explicitement spécifiée
+ causera une erreur du serveur si elle est rencontrée dans un fichier
+ <code>.htaccess</code>. C’est un bon compromis entre possibilité et
+ impossibilité totales d’outrepasser la configuration globale.</p>
+
<p>Notez que mettre un fichier <code>.htaccess</code> contenant une
directive dans un répertoire <code>/www/htdocs/exemple</code>
revient exactement au même que mettre la même directive dans une
</highlight>
</example>
- <p>Cependant, la perte de performances sera moindre si vous
- définissez cette directive dans la configuration de
- votre serveur principal, car cette dernière ne sera chargée qu'une
- seule fois au moment du démarrage du serveur, alors qu'elle le sera
- à chaque accès dans le cas d'un fichier <code>.htaccess</code>.</p>
-
<p>L'utilisation des fichiers <code>.htaccess</code> peut être
entièrement désactivée en définissant la directive <directive
module="core">AllowOverride</directive> à <code>none</code> :</p>
<section id="auth"><title>Exemple d'authentification</title>
- <p>Si vous accédez directement à ce point du document pour apprendre
- à effectuer une authentification, il est important de noter ceci. Il
- existe une fausse idée selon laquelle il serait nécessaire
- d'utiliser les fichiers <code>.htaccess</code> pour implémenter
- l'authentification par mot de passe. Ceci est tout simplement faux.
- Pour y parvenir, il est préférable de mettre les directives
- d'authentification dans une section <directive module="core"
- type="section">Directory</directive> du fichier de configuration de
- votre serveur principal, et les fichiers <code>.htaccess</code> ne
- devraient être utilisés que dans le cas où vous n'avez pas accès au
- fichier de configuration du serveur principal. Voir <a
- href="#when">ci-dessus</a> pour savoir dans quels cas vous devez ou
- ne devez pas utiliser les fichiers <code>.htaccess</code>.</p>
-
- <p>Ceci étant dit, si vous pensez que vous devez quand-même utiliser
- un fichier <code>.htaccess</code>, vous pouvez utiliser la
- configuration suivante :</p>
+ <p>Comme avec toute utilisation de fichier <code>.htaccess</code>, placer
+ ces directives dans une section <directive module="core"
+ type="section">Directory</directive> est préférable si vous avez accès au
+ fichier de configuration principal (voir <a href="#when">ci-avant</a>).
+ L’exemple suivant montre l’approche <code>.htaccess</code> :</p>
<p>Contenu du fichier <code>.htaccess</code> :</p>
<section id="ssi"><title>Exemple d'Inclusion Côté Serveur (Server Side
Includes - SSI)</title>
- <p>Les fichiers <code>.htaccess</code> sont aussi couramment
- utilisés pour activer les SSI pour un répertoire particulier. Pour y
- parvenir, on utilise les directives de configuration suivantes,
- placées dans un fichier <code>.htaccess</code> enregistré dans le
- répertoire considéré :</p>
+ <p>Les fichiers <code>.htaccess</code> 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 <code>.htaccess</code> enregistré dans le répertoire considéré :</p>
<highlight language="config">
Options +Includes
remplacement. Il doit donc en être de même dans votre expression
rationnelle.</p>
+<p>Notez aussi que dans un contexte <code>.htaccess</code>, 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.</p>
+
<p>Veuillez vous référer à cette <a href="../rewrite/">documentation</a>
pour une étude détaillée de l'utilisation du module
-<code>mod_rewrite</code>.</p>
+<module>mod_rewrite</module>.</p>
</section>
<section id="cgi"><title>Exemple de CGI</title>
- <p>En fin de compte, vous avez décidé d'utiliser un fichier
- <code>.htaccess</code> pour permettre l'exécution des programmes CGI
- dans un répertoire particulier. Pour y parvenir, vous pouvez
- utiliser la configuration suivante :</p>
+ <note>Les scripts CGI constituent un mécanisme de gestion de contenu
+ dynamique patrimonial. Pour les nouveaux déploiements, pensez à utiliser
+ <module>mod_proxy_fcgi</module> 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.</note>
+
+ <p>Vous pouvez utiliser un fichier <code>.htaccess</code> pour autoriser
+ l’exécution de programmes CGI dans un répertoire particulier. Pour y
+ parvenir, vous pouvez utiliser la configuration suivante :</p>
<highlight language="config">
Options +ExecCGI
-AddHandler cgi-script "cgi" "pl"
+AddHandler cgi-script "cgi" "py"
</highlight>
<p>Alternativement, si vous souhaitez que tous les fichiers d'un
les directives que vous avez mises dans un fichier
<code>.htaccess</code> ne produisent pas l'effet désiré.</p>
- <p>Le plus souvent, le problème vient du fait que la définition de
- la directive <directive module="core">AllowOverride</directive>
- ne permet pas l'activation des directives de votre fichier
- <code>.htaccess</code>. Vérifiez si une directive
- <code>AllowOverride None</code> n'affecte pas le répertoire où se
- trouve votre fichier. Un bon test consiste à mettre des directives
- dont la syntaxe est erronée dans votre ficher <code>.htaccess</code>
- et de recharger la page. Si aucune erreur n'est générée par le
+ <p>Le plus souvent, le problème vient du fait que la définition de la
+ directive <directive module="core">AllowOverride</directive> ne permet pas
+ l'activation des directives de votre fichier <code>.htaccess</code>.
+ Vérifiez si une directive <code>AllowOverride None</code> 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 <code>.htaccess</code> et de recharger la
+ page :</p>
+
+ <highlight language="config">
+TestMe
+ </highlight>
+
+ <p>Si aucune erreur (HTTP 500) n'est générée par le
serveur, il est pratiquement certain qu'une directive
<code>AllowOverride None</code> affecte votre répertoire.</p>
utilisée dans votre fichier <code>.htaccess</code> n'est pas
permise.</p>
-<example>
- [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here
-</example>
+ <highlight language="config">
+[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
+ </highlight>
+
<p>Cela signifie soit que vous utilisez une directive qui n'est
jamais permise dans les fichiers <code>.htaccess</code>, soit
que vous n'avez tout simplement pas défini la directive
<p>Le journal des erreurs peut aussi vous signaler une erreur de
syntaxe dans l'usage de la directive elle-même.</p>
- <example>
- [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
- </example>
+ <highlight language="config">
+[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
+ </highlight>
<p>Dans ce cas, le message d'erreur sera spécifique à l'erreur
de syntaxe que vous avez commise.</p>
projects / thirdparty / apache / httpd.git / commitdiff
