| Current Path : /usr/local/apache22/share/doc/apache2/rewrite/ |
FreeBSD hs32.drive.ne.jp 9.1-RELEASE FreeBSD 9.1-RELEASE #1: Wed Jan 14 12:18:08 JST 2015 root@hs32.drive.ne.jp:/sys/amd64/compile/hs32 amd64 |
| Current File : //usr/local/apache22/share/doc/apache2/rewrite/tech.html.fr |
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
<!--
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
<title>Détails techniques sur le module Apache mod_rewrite - Serveur Apache HTTP Version 2.2</title>
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" />
<script src="../style/scripts/prettify.min.js" type="text/javascript">
</script>
<link href="../images/favicon.ico" rel="shortcut icon" /><link href="http://httpd.apache.org/docs/current/rewrite/tech.html" rel="canonical" /></head>
<body id="manual-page"><div id="page-header">
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
<p class="apache">Serveur Apache HTTP Version 2.2</p>
<img alt="" src="../images/feather.gif" /></div>
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.2</a> > <a href="./">Rewrite</a></div><div id="page-content"><div class="retired"><h4>A savoir</h4>
<p>Ce document concerne une version ancienne (<strong>2.2</strong>)
du serveur HTTP Apache. La version actuelle est
documentée <a href="http://httpd.apache.org/docs/current">ici</a>. Si vous n'avez
pas encore effectué la mise è jour, veuillez suivre <a href="http://httpd.apache.org/docs/current/upgrading.html">ce
lien</a> pour plus d'informations.</p>
<p>Pour consulter la version actuelle de ce
document, vous pouvez suivre <a href="http://httpd.apache.org/docs/current/rewrite/tech.html">ce lien</a>.</p></div><div id="preamble"><h1>Détails techniques sur le module Apache mod_rewrite</h1>
<div class="toplang">
<p><span>Langues Disponibles: </span><a href="../en/rewrite/tech.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/rewrite/tech.html" title="Français"> fr </a></p>
</div>
<p>Ce document passe en revue certains détails techniques à propos du
module mod_rewrite et de la mise en correspondance des URLs</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#Internal">Fonctionnement interne</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#InternalAPI">Phases de l'API</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#InternalRuleset">Traitement du jeu de règles</a></li>
</ul><h3>Voir aussi</h3><ul class="seealso"><li><a href="../mod/mod_rewrite.html">Documentation du module mod_rewrite</a></li><li><a href="intro.html">Introduction à mod_rewrite</a></li><li><a href="remapping.html">Redirection et remise en
correspondance</a></li><li><a href="access.html">Contrôle d'accès</a></li><li><a href="vhosts.html">Serveurs virtuels</a></li><li><a href="proxy.html">Mise en cache</a></li><li><a href="rewritemap.html">Utilisation de RewriteMap</a></li><li><a href="advanced.html">Techniques avancées et astuces</a></li><li><a href="avoid.html">Quand ne pas utiliser mod_rewrite</a></li></ul><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="Internal" id="Internal">Fonctionnement interne</a></h2>
<p>Le fonctionnement interne de ce module est très complexe, mais
il est nécessaire de l'expliquer, même à l'utilisateur "standard",
afin d'éviter les erreurs courantes et de pouvoir exploiter toutes
ses fonctionnalités.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="InternalAPI" id="InternalAPI">Phases de l'API</a></h2>
<p>Il faut tout d'abord bien comprendre que le traitement d'une
requête HTTP par Apache s'effectue en plusieurs phases. L'API
d'Apache fournit un point d'accroche (hook) pour chacune de ces
phases. Mod_rewrite utilise deux de ces hooks : le hook de
conversion des URLs en noms de fichiers qui est utilisé quand la
requête HTTP a été lue mais avant le démarrage de tout processus
d'autorisation, et le hook "Fixup" qui est déclenché après les
phases d'autorisation et après la lecture des fichiers de
configuration niveau répertoire (<code>.htaccess</code>), mais
avant que le gestionnaire de contenu soit activé.</p>
<p>Donc, lorsqu'une requête arrive et quand Apache a déterminé le
serveur correspondant (ou le serveur virtuel), le moteur de
réécriture commence le traitement de toutes les directives de
mod_rewrite de la configuration du serveur principal dans la phase
de conversion URL vers nom de fichier. Une fois ces étapes
franchies, lorsque les repertoires de données finaux ont été
trouvés, les directives de configuration de mod_rewrite au niveau
répertoire sont éxécutées dans la phase Fixup. Dans les deux cas,
mod_rewrite réécrit les URLs soit en nouvelles URLs, soit en noms
de fichiers, bien que la distinction entre les deux ne soit pas
évidente. Cette utilisation de l'API n'était pas sensée s'opérer
de cette manière lorsque l'API fut conçue, mais depuis Apache 1.x,
c'est le seul mode opératoire possible pour mod_rewrite. Afin de
rendre les choses plus claires, souvenez-vous de ces deux points :</p>
<ol>
<li>Bien que mod_rewrite réécrive les URLs en URLs, les URLs en
noms de fichiers et même des noms de fichiers en d'autres noms
de fichiers, l'API ne propose actuellement qu'un hook URL vers
nom de fichier. Les deux hooks manquants seront ajoutés dans
Apache à partir de la version 2.0 afin de rendre le processus
plus clair. Mais ce point ne présente pas d'inconvénient pour
l'utilisateur, il s'agit simplement d'un fait que vous devez
garder à l'esprit : Apache en fait plus avec le hook URL vers
nom de fichier que l'API n'a la prétention d'en faire.</li>
<li>
Paradoxalement, mod_rewrite permet la manipulation d'URLs dans
un contexte de répertoire, <em>c'est à dire</em> dans les
fichiers <code>.htaccess</code>, bien que ces derniers
soient traités bien longtemps après que les URLs n'aient été
traduites en noms de fichiers. Les choses doivent se dérouler
ainsi car les fichiers <code>.htaccess</code> résident dans le
système de fichiers, et le traitement a déjà atteint
cette étape. Autrement dit, en accord avec les phases de
l'API, à ce point du traitement, il est trop tard pour
effectuer des manipulations d'URLs. Pour résoudre ce problème
d'antériorité, mod_rewrite utilise une astuce : pour effectuer
une manipulation URL/nom de fichier dans un contexte de
répertoire, mod_rewrite réécrit tout d'abord le nom de fichier
en son URL d'origine (ce qui est normalement impossible, mais
voir ci-dessous l'astuce utilisée par la directive
<code>RewriteBase</code> pour y parvenir), puis
initialise une nouvelle sous-requête interne avec la nouvelle
URL ; ce qui a pour effet de redémarrer le processus des
phases de l'API.
<p>Encore une fois, mod_rewrite fait tout ce qui est en son
pouvoir pour rendre la complexité de cette étape complètement
transparente à l'utilisateur, mais vous devez garder ceci à
l'esprit : alors que les manipulations d'URLs dans le contexte
du serveur sont vraiment rapides et efficaces, les réécritures
dans un contexte de répertoire sont lentes et inefficaces à
cause du problème d'antériorité précité. Cependant, c'est la
seule manière dont mod_rewrite peut proposer des manipulations
d'URLs (limitées à une branche du système de fichiers) à
l'utilisateur standard.</p>
</li>
</ol>
<p>Ne perdez pas de vue ces deux points!</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="InternalRuleset" id="InternalRuleset">Traitement du jeu de règles</a></h2>
<p>Maintenant, quand mod_rewrite se lance dans ces deux phases de
l'API, il lit le jeu de règles configurées depuis la structure
contenant sa configuration (qui a été elle-même créée soit au
démarrage d'Apache pour le contexte du serveur, soit lors du
parcours des répertoires par le noyau d'Apache pour le contexte de
répertoire). Puis le moteur de réécriture est démarré avec le jeu
de règles contenu (une ou plusieurs règles associées à leurs
conditions). En lui-même, le mode opératoire du moteur de
réécriture d'URLs est exactement le même dans les deux contextes
de configuration. Seul le traitement du résultat final diffère.</p>
<p>L'ordre dans lequel les règles sont définies est important car
le moteur de réécriture les traite selon une chronologie
particulière (et pas très évidente). Le principe est le suivant :
le moteur de réécriture traite les règles (les directives <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code>) les unes
à la suite des autres, et lorsqu'une règle s'applique, il parcourt
les éventuelles conditions (directives
<code>RewriteCond</code>directives) associées.
Pour des raisons historiques, les
conditions précèdent les règles, si bien que le déroulement du
contrôle est un peu compliqué. Voir la figure 1 pour plus de
détails.</p>
<p class="figure">
<img src="../images/rewrite_rule_flow.png" alt="Flux des comparaisons des directives RewriteRule et RewriteCond" /><br />
<dfn>Figure 1:</dfn>Déroulement du contrôle à travers le jeu de
règles de réécriture
</p>
<p>Comme vous pouvez le voir, l'URL est tout d'abord comparée au
<em>Modèle</em> de chaque règle. Lorsqu'une règle ne s'applique
pas, mod_rewrite stoppe immédiatement le traitement de cette règle
et passe à la règle suivante. Si l'URL correspond au
<em>Modèle</em>, mod_rewrite recherche la présence de conditions
correspondantes. S'il n'y en a pas, mod_rewrite remplace
simplement l'URL par une chaîne élaborée à partir de la chaîne de
<em>Substitution</em>, puis passe à la règle suivante. Si des
conditions sont présentes, mod_rewrite lance un bouclage
secondaire afin de les traiter selon l'ordre dans lequel elles
sont définies. La logique de traitement des conditions est
différente : on ne compare pas l'URL à un modèle. Une chaîne de
test <em>TestString</em> est tout d'abord élaborée en développant
des variables, des références arrières, des recherches dans des
tables de correspondances, etc..., puis cette chaîne de test est
comparée au modèle de condition <em>CondPattern</em>. Si le modèle
ne correspond pas, les autres conditions du jeu ne sont pas
examinées et la règle correspondante ne s'applique pas. Si le
modèle correspond, la condition suivante est examinée et ainsi de
suite jusqu'à la dernière condition. Si toutes les conditions sont
satisfaites, le traitement de la règle en cours se poursuit avec
le remplacement de l'URL par la chaîne de <em>Substitution</em>.</p>
</div></div>
<div class="bottomlang">
<p><span>Langues Disponibles: </span><a href="../en/rewrite/tech.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/rewrite/tech.html" title="Français"> fr </a></p>
</div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Commentaires</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
<script type="text/javascript"><!--//--><![CDATA[//><!--
var comments_shortname = 'httpd';
var comments_identifier = 'http://httpd.apache.org/docs/2.2/rewrite/tech.html';
(function(w, d) {
if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
d.write('<div id="comments_thread"><\/div>');
var s = d.createElement('script');
s.type = 'text/javascript';
s.async = true;
s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
(d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
}
else {
d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
}
})(window, document);
//--><!]]></script></div><div id="footer">
<p class="apache">Copyright 2017 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
if (typeof(prettyPrint) !== 'undefined') {
prettyPrint();
}
//--><!]]></script>
</body></html>