<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1788719:1933457 (outdated) -->
+<!-- English Revision: 1933457 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
Apache</compatibility>
<usage>
- <p>La directive <directive>CacheSocacheMaxSize</directive>
- définit la taille maximale, en octets, de la somme des en-têtes et
- du corps d'un document pouvant être stocké dans le cache. Bien
- entendu, plus la taille des en-têtes sera grande, plus la taille
- maximale du corps du document s'en trouvera réduite.</p>
+ <p>La directive <directive>CacheSocacheMaxSize</directive> définit la taille
+ maximale, en octets, de la somme des en-têtes et du corps d'un document
+ pouvant être stocké dans le cache. La valeur minimale est 1024 octets. Bien
+ entendu, plus la taille des en-têtes sera grande, plus la taille maximale du
+ corps du document s'en trouvera réduite.</p>
<p>Le module <module>mod_cache_socache</module> ne tentera de mettre
en cache que des réponses qui possèdent une taille de contenu
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1330988:1933749 (outdated) -->
+<!-- English Revision: 1933749 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
obtenue à partir du document source.</p>
<p>Pour modifier les directives de contrôle du cache autres
- que <code>max-age</code> (voir la <a
- href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9">RFC
- 2616 section 14.9</a>), vous pouvez utiliser la directive <directive
+ que <code>max-age</code> (voir la <rfc section="14.9">2616</rfc>,
+ section 14.9)), vous pouvez utiliser la directive <directive
module="mod_headers">Header</directive>.</p>
<p>Lorsque l'en-tête <code>Expires</code> est déjà présent dans la
<p>Vous pouvez aussi définir le mode de calcul de la date
d'expiration en utilisant une <a href="#AltSyn">syntaxe
alternative</a>, comme décrit plus haut dans ce document.</p>
+
+ <p>Le type MIME peut utiliser des caractères génériques pour le sous-type,
+ comme dans <code>image/*</code>. Cet exemple correspond à tout sous-type
+ sous le type principal. Lorsque le type de contenu d’une requête ne
+ correspond pas à une entrée <directive>ExpiresByType</directive> spécifique,
+ une entrée avec caractères génériques pour le type principal est recherchée
+ avant de se rebattre sur <directive
+ module="mod_expires">ExpiresDefault</directive>.</p>
+
+ <example><title>Exemple avec caractères génériques ::</title>
+ <highlight language="config">
+ExpiresActive On
+# Toutes les images sont périmées après 1 mois
+ExpiresByType image/* "access plus 1 month"
+# Override specifically for GIF
+ExpiresByType image/gif "access plus 1 week"
+ </highlight>
+ </example>
</usage>
</directivesynopsis>
<?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: 1933438:1934111 (outdated) -->
+<!-- English Revision: 1934111 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<manualpage metafile="index.xml.meta">
<parentdocument href="../"/>
- <title>Le module Apache mod_rewrite</title>
+ <title>Guide pour le module Apache mod_rewrite</title>
<summary>
+<p><em>Le point fort de mod_rewrite réside dans le fait qu’il possède toutes les
+capacités de configuration et la flexibilité de Sendmail ;mais c’est aussi son
+point faible.</em>
+-- Brian Behlendorf</p>
+
+<p><em>Malgré la multitude d'exemples et de documentations, mod_rewrite est de
+la magie noire. De la magie noire très "cool", mais de la magie noire
+quand-même.</em></p>
<p><module>mod_rewrite</module> permet de modifier les requêtes
entrantes dynamiquement, en fonction de règles manipulant des <a
ainsi relier des URLs arbitraires à votre propre structure d'URLs
interne comme vous le souhaitez.</p>
- <p>Il fournit un
- mécanisme de manipulation d'URL particulièrement souple et
- puissant en supportant un nombre illimité de règles et de
- conditions attachées à chaque règle. Les manipulations d'URLs
- peuvent dépendre de tests variés : les URLs peuvent
- être finement caractérisées en fonction de variables du serveur,
- de variables d'environnement, d'en-têtes HTTP, de repères
- temporels, de recherches dans des bases de données
- externes, ou même de requêtes vers des bases de données externes
- et de différents gestionnaires ou programmes externes.</p>
-
- <p>Les règles de réécriture peuvent agir sur l'ensemble des URLs (la partie chemin
- et la chaîne de paramètres) et peuvent être utilisées dans le contexte du serveur principal
- (<code>httpd.conf</code>), mais aussi dans le contexte des
- serveurs virtuels (sections <directive
- type="section" module="core">VirtualHost</directive>), ou dans le
- contexte des
- répertoires (fichiers <code>.htaccess</code> et blocs
- <directive type="section" module="core">Directory</directive>). Le résultat
- réécrit peut conduire vers d'autres règles à un
- traitement secondaire interne, une redirection vers une requête
- externe ou même l'envoi vers un serveur mandataire, en fonction
- des <a href="flags.html">drapeaux</a> que vous attachez aux
- règles</p>
-
- <p><module>mod_rewrite</module> étant très puissant, il peut par
- conséquent être très complexe. Ce document
- complète la <a
- href="../mod/mod_rewrite.html">documentation de
- référence du module mod_rewrite</a>, et est sensé alléger un
- peu cette complexité, et présenter des exemples largement
- commentés, ainsi que des situations courantes que vous
- pourrez traiter avec <module>mod_rewrite</module>. Mais nous voulons aussi vous
- montrer des situations où vous ne devrez pas utiliser
- <module>mod_rewrite</module>, et lui préférer d'autres
- fonctionnalités standard d'Apache, évitant ainsi
- d'entrer dans une complexité inutile.</p>
-
-<ul>
-<li><a href="../mod/mod_rewrite.html">documentation de
-référence de mod_rewrite</a></li>
-<li><a href="intro.html">Introduction aux expressions rationnelles et à
-mod_rewrite</a></li>
-<li><a href="flags.html">Drapeaux de réécriture</a></li>
-<li><a href="rewritemap.html">Utilisation de RewriteMap</a></li>
-<li><a href="avoid.html">Quand <strong>NE PAS</strong> utiliser mod_rewrite</a></li>
-<li><a href="remapping.html">Utilisation de mod_rewrite pour la
-redirection et la remise en correspondance des URLs</a></li>
-<li><a href="access.html">Utilisation de mod_rewrite pour le
-contrôle d'accès</a></li>
-<li><a href="vhosts.html">Les serveurs virtuels dynamiques avec mod_rewrite</a></li>
-<li><a href="proxy.html">Les serveurs mandataires dynamiques avec mod_rewrite</a></li>
-<li><a href="advanced.html">Techniques avancées</a></li>
-<li><a href="tech.html">Détails techniques</a></li>
-</ul>
+<p>Ce guide est un complément du <a href="../mod/mod_rewrite.html">manuel de
+référence</a> avec des exemples commentés, des explications conceptuelles et des
+conseils pratiques. Il est organisé comme suit :</p>
+
+<dl>
+<dt><a href="intro.html">Introduction</a></dt>
+<dd>Concepts de base : syntaxe des expressions rationnelles, les bases des
+directives RewriteRule et RewriteCond et la manière dont mod_rewrite s’insère
+dans le cycle de vie du traitement des requêtes.</dd>
+
+<dt><a href="htaccess.html">Réécritures en fonction du répertoire</a></dt>
+<dd>Les principales différences entre l’utilisation des règles de réécriture au
+niveau de la configuration globale du serveur et leur utilisation dans un
+contexte de <glossary ref="perdirectory">répertoire</glossary>, y compris la
+suppression du chemin, RewriteBase et la gestion du bouclage par le drapeau [L].</dd>
+
+<dt><a href="flags.html">Drapeaux des règles de réécriture</a></dt>
+<dd>Une référence complète de tous les drapeaux qui peuvent modifier le
+comportement d’une règle de réécriture avec des exemples pour chacun d’entre
+eux.</dd>
+
+<dt><a href="rewritemap.html">Utiliser RewriteMap</a></dt>
+<dd>Comment utiliser des sources de recherche externes — fichiers texte,
+bases de données DBM, requêtes SQL et fonctions internes — pour piloter
+vos règles de réécriture.</dd>
+
+<dt><a href="remapping.html">Redirection et remappage</a></dt>
+<dd>Des recettes pour les tâches courantes : redirection HTTPS, noms d’hôte
+canoniques, normalisation des barres obliques de fin, routage du contrôleur
+frontal, et plus encore.</dd>
+
+<dt><a href="vhosts.html">Serveurs virtuels dynamiques</a></dt>
+<dd>Utilisation de mod_rewrite pour associer dynamiquement les noms d’hôte aux
+racines de document sans devoir créer des blocs VirtualHost individuels.</dd>
+
+<dt><a href="avoid.html">Quand ne pas utiliser mod_rewrite</a></dt>
+<dd>De nombreuses tâches courantes sont accomplies de manière bien plus efficace
+avec des directives plus simples. Ce document vous propose des solutions de
+remplacement et vous indique quand il est préférable de les utiliser.</dd>
+
+<dt><a href="tech.html">Détails techniques</a></dt>
+<dd>Comment mod_rewrite s’insère dans les phases de traitement des requêtes par
+httpd et l’ordre dans lequel les règles et les conditions sont évaluées.</dd>
+</dl>
</summary>
<seealso><a href="../mod/mod_rewrite.html">Documentation de
<?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: 1933438:1934122 (outdated) -->
+<!-- English Revision: 1934122 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<seealso><a href="intro.html">Introduction à mod_rewrite</a></seealso>
<seealso><a href="remapping.html">Redirection et remise en
correspondance</a></seealso>
-<seealso><a href="access.html">Contrôle d'accès</a></seealso>
+<seealso><a href="flags.html">Drapeaux de réécriture</a></seealso>
<seealso><a href="vhosts.html">Serveurs virtuels</a></seealso>
-<seealso><a href="proxy.html">Mise en cache</a></seealso>
<seealso><a href="rewritemap.html">Utilisation de RewriteMap</a></seealso>
-<seealso><a href="advanced.html">Techniques avancées</a></seealso>
+<seealso><a href="htaccess.html">Réécritures en fonction du répertoire</a></seealso>
<seealso><a href="avoid.html">Quand ne pas utiliser mod_rewrite</a></seealso>
<section id="InternalAPI"><title>Phases de l'API</title>
<code>REQUEST_URI</code> soit vers une nouvelle URL, soit vers un
nom de fichier.</p>
- <p>Dans un contexte de niveau répertoire (autrement dit dans les
- fichiers <code>.htaccess</code> et les sections
- <code>Directory</code>), les règles de réécriture s'appliquent après
- la traduction de l'URL en nom de fichier. C'est pourquoi le chemin
- URL auquel <module>mod_rewrite</module> compare initialement les directives
- <directive module="mod_rewrite">RewriteRule</directive> est le
- chemin complet vers le nom de fichier traduit amputé de la partie
- répertoires (y compris le dernier slash).</p>
-
- <p>Un exemple : si les règles se trouvent dans
- /var/www/foo/.htaccess et si une requête pour /foo/bar/baz est
- traité, une expression comme ^bar/baz$ correspondra.</p>
-
- <p>Si une substitution intervient dans un contexte de répertoire,
- une nouvelle sous-requête interne est générée avec la nouvelle URL,
- ce qui relance le traitement des phases de la requête. Si la
- substitution est un chemin relatif, la directive <directive
- module="mod_rewrite">RewriteBase</directive> détermine le chemin URL
- devant préfixer cette substitution. Dans un contexte de répertoire,
- il faut s'assurer de créer des règles qui
- n'effectueront pas de substitution au
- cours d'une passe ultérieure du processus de réécriture au niveau
- répertoire afin d'éviter les bouclages . Voir <a
- href="https://cwiki.apache.org/confluence/display/httpd/RewriteLooping">Bouclage dans le
- processus de réécriture</a> pour une discussion plus détaillée à
- propos de ce problème.</p>
-
- <p>En conséquence de cette manipulation de l'URL , vous devrez
- pensez à confectionner différemment vos règles de réécriture dans un
- contexte de niveau répertoire. En particulier, rappelez-vous que le
- chemin de répertoire sera absent de l'URL que vos règles de
- réécriture verront. Voici quelques exemples qui permettront de
- clarifier les choses :</p>
-
- <table border="1">
-
- <tr>
- <th>Position de la règle</th>
- <th>Règle</th>
- </tr>
-
- <tr>
- <td>Section VirtualHost</td>
- <td>RewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"</td>
- </tr>
-
- <tr>
- <td>Fichier .htaccess à la racine des documents</td>
- <td>RewriteRule "^images/(.+)\.jpg" "images/$1.gif"</td>
- </tr>
-
- <tr>
- <td>Fichier .htaccess dans le répertoire images</td>
- <td>RewriteRule "^(.+)\.jpg" "$1.gif"</td>
- </tr>
-
- </table>
-
- <p>Pour une étude plus approfondie de la manière dont <module>mod_rewrite</module>
- manipule les URLs dans les différents contextes, vous pouvez
- consulter les <a href="../mod/mod_rewrite.html#logging">entrées du
- journal</a> générées au cours du processus de réécriture.</p>
+ <p>Dans un <glossary ref="perdirectory">contexte de répertoire</glossary>,
+ les règles sont appliquées durant la phase "Fixup" après que l’URL a été
+ traduite en nom de fichier. Cela modifie ce à quoi correspond le motif et la
+ manière dont les substitutions sont gérées. Voir le document <a
+ href="htaccess.html#path-stripping">Réécritures en fonction du
+ répertoire</a> pour des détails pratiques à propos de la suppression du
+ chemin, de RewriteBase et de la manière d’éviter un bouclage.</p>
</section>
projects / thirdparty / apache / httpd.git / commitdiff
