<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision : 1296177 -->
+<!-- English Revision : 1308341 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<description>Définit l'URL de base pour les réécritures au niveau
répertoire</description>
<syntax>RewriteBase <em>chemin URL</em></syntax>
-<default>Voir utilisation pour plus d'informations.</default>
+<default>None</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<usage>
- <p>La directive <directive>RewriteBase</directive> définit
- explicitement l'URL de base pour les réécritures au niveau du
- répertoire. Comme vous le verrez plus loin, la directive
- <directive module="mod_rewrite">RewriteRule</directive> peut
- être utilisée dans les fichiers de configuration au niveau du
- répertoire (<code>.htaccess</code>). Elle agit alors localement,
- en amputant le répertoire local de son préfixe avant traitement,
- et en n'appliquant les règles de réécriture que sur ce qui reste
- de l'URL. Lorsque le traitement est terminé, le préfixe est
- automatiquement rajouté à l'URL. La valeur par défaut est
- <directive>RewriteBase</directive>
- <em>chemin répertoire physique</em></p>
-
- <p>Lorsqu'une substitution intervient pour une nouvelle URL, ce
- module doit réinjecté l'URL dans le traitement du serveur. Pour
- y parvenir, il doit connaître le préfixe de l'URL ou l'URL de
- base correspondants. Par défaut, le préfixe est le chemin du
- fichier correspondant lui-même. <strong>Cependant, pour la
- plupart des sites web, les URLs ne correspondent PAS directement
- aux chemins des fichiers physiques, cette assertion s'avère
- ainsi souvent fausse !</strong>. C'est pourquoi vous pouvez
- utiliser la directive <code>RewriteBase</code> pour spécifier
- le préfixe correct.</p>
-
-<note> Si les URLs de votre serveur web ne correspondent
-<strong>pas</strong> directement aux chemins physiques des fichiers,
-vous devrez utiliser <directive>RewriteBase</directive> dans chaque
-fichier <code>.htaccess</code> où vous voudrez utiliser des
-directives <directive
-module="mod_rewrite">RewriteRule</directive>.
-</note>
+ <p>La directive <directive>RewriteBase</directive> permet de
+ spécifier le préfixe d'URL à utiliser dans un contexte de
+ répertoire (htaccess) pour les directives
+ <directive>RewriteRule</directive> qui réécrivent vers un chemin
+ relatif.</p>
+ <p>Cette directive est <em>obligatoire</em> si vous utilisez un
+ chemin relatif dans une substitution, et dans un contexte de
+ répertoire (htaccess), sauf si au moins une de ces conditions est
+ vérifiée :</p>
+ <ul>
+ <li>La requête initiale, ainsi que la substitution, sont dans
+ la <directive module="core">DocumentRoot</directive> (c'est à
+ dire que pour y accéder, il n'est pas nécessaire d'utiliser
+ une directive telle qu'<directive
+ module="mod_alias">Alias</directive>).</li>
+ <li>Le chemin du système de fichiers vers le répertoire
+ contenant la <directive>RewriteRule</directive>, suffixé par
+ la substitution relative est aussi valide en tant qu'URL sur
+ le serveur (ce qui est rare).</li>
+ </ul>
- <p> Par exemple, considérons le fichier de configuration de
- répertoire suivant :</p>
+<p>Dans l'exemple ci-dessous, la directive
+<directive>RewriteBase</directive> est nécessaire afin d'éviter une
+réécriture en http://example.com/opt/myapp-1.2.3/welcome.html car la
+ressource n'était pas relative à la racine des documents. Cette erreur
+de configuration aurait conduit le serveur à rechercher un répertoire
+"opt" à la racine des documents.</p>
<example>
<pre>
-#
-# /abc/def/.htaccess -- fichier de configuration pour le répertoire
-/abc/def
-# Rappel : /abc/def est le chemin physique de /xyz,
-# <em>ce qui veut dire</em> que la configuration du serveur comporte
-# une directive du style 'Alias /xyz /abc/def'.
-#
-
+DocumentRoot /var/www/example.com
+Alias /myapp /opt/myapp-1.2.3
+<Directory /opt/myapp-1.2.3>
RewriteEngine On
-
-# faisons savoir au serveur qu'on nous a atteint via /xyz et non par
-# le chemin physique /abc/def
-RewriteBase /xyz
-
-# maintenant les règles de réécriture
-RewriteRule ^avant\.html$ après.html
+RewriteBase /myapp/
+RewriteRule ^index\.html$ welcome.html
+</Directory>
</pre>
</example>
-
- <p>Dans l'exemple précédent, une requête pour
- <code>/xyz/avant.html</code> sera correctement réécrite sous
- sous sa forme chemin physique
- <code>/abc/def/après.html</code>.</p>
-
-<note><title>Pour les hackers d'Apache</title>
-<p>La liste suivante fournit des informations détaillées à propos des
-étapes du traitement interne :</p>
-<pre>
-Requête :
- /xyz/avant.html
-
-Traitement interne :
- /xyz/avant.html -> /abc/def/avant.html (Alias au niveau serveur)
- /abc/def/avant.html -> /abc/def/après.html (RewriteRule au niveau répertoire)
- /abc/def/après.html -> /xyz/après.html (RewriteBase au niveau répertoire)
- /xyz/après.html -> /abc/def/après.html (Alias au niveau serveur)
-
-Résultat :
- /abc/def/après.html
-
-</pre>
- <p>Tout ceci paraît très compliqué, mais correspond
- réellement au traitement interne d'Apache. Comme la
- réécriture au niveau du répertoire intervient plus tard
- au cours du traitement, la requête de réécriture doit être
- réinjectée dans le noyau d'Apache, comme s'il s'agissait
- d'une nouvelle requête (Voir les <a
- href="../rewrite/tech.html">détails techniques à
- propos de mod_rewrite</a>). La surcharge
- correspondante n'est pas aussi importante qu'il n'y
- paraît, car la réinjection est entièrement prise en charge
- en interne par Apache (comme c'est d'ailleurs le cas pour
- de nombreuses autres opérations effectuées à l'intérieur
- d'Apache).</p>
-</note>
-
</usage>
</directivesynopsis>
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
-<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
-<!-- English Revision: 421100 -->
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision: 1309686 -->
<!-- French translation by alain B, review by Vincent Deffontaines -->
+<!-- Maintained by Lucien Gentis -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
que le processus résident doit gérer. Par exemple :</p>
<example>
- Listen www.smallco.com:80
+ Listen 192.168.0.1:80
</example>
<p>Il est recommandé d'utiliser une adresse IP plutôt qu'un nom
valeurs différentes pour chaque serveur virtuel. Par exemple :</p>
<example>
- <VirtualHost www.smallco.com><br />
- ServerAdmin webmaster@mail.smallco.com<br />
+ <VirtualHost 192.168.0.1:80><br />
+ ServerAdmin webmaster@smallco.example.com<br />
DocumentRoot /groups/smallco/www<br />
- ServerName www.smallco.com<br />
+ ServerName smallco.example.com<br />
ErrorLog /groups/smallco/logs/error_log<br />
TransferLog /groups/smallco/logs/access_log<br />
</VirtualHost><br />
<br />
- <VirtualHost www.baygroup.org><br />
- ServerAdmin webmaster@mail.baygroup.org<br />
+ <VirtualHost 192.168.0.2:80><br />
+ ServerAdmin webmaster@baygroup.example.org<br />
DocumentRoot /groups/baygroup/www<br />
- ServerName www.baygroup.org<br />
+ ServerName baygroup.example.com<br />
ErrorLog /groups/baygroup/logs/error_log<br />
TransferLog /groups/baygroup/logs/access_log<br />
</VirtualHost>
en remplacement depuis la version 2.0.</p>
-->
<p><directive module="mod_suexec">SuexecUserGroup</directive> peut être
- utilisée à l'intérieur d'une directive VirtualHost si l'exécution se fait
+ utilisées à l'intérieur d'une directive VirtualHost si l'exécution se fait
sous suEXEC. (Voir <a href="../suexec.html">suEXEC</a>).</p>
<p><em>SÉCURITÉ :</em> lorsque vous spécifiez où écrire les
projects / thirdparty / apache / httpd.git / commitdiff
