+++ /dev/null
-<?xml version="1.0" encoding="ISO-8859-1" ?>
-<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
-<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision : 774161 -->
-<!-- French translation : Lucien GENTIS -->
-<!-- Reviewed by : Vincent Deffontaines -->
-
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<manualpage metafile="rewrite_guide.xml.meta">
- <parentdocument href="./">Rewrite</parentdocument>
-
- <title>Guide de réécriture des URLs</title>
-
- <summary>
-
- <p>Ce document complète la <a
- href="../mod/mod_rewrite.html">documentation de référence</a> du
- module <module>mod_rewrite</module>. Il décrit de quelle manière on
- peut utiliser le module Apache <module>mod_rewrite</module> pour
- résoudre les problèmes typiques relatifs aux URLs auxquels les
- webmasters sont souvent confrontés. La résolution de chaque problème
- par la configuration des jeux de règles de réécriture d'URLs fait
- l'objet d'une description détaillée.</p>
-
- <note type="warning">ATTENTION : l'adaptation des exemples à votre
- situation en fonction de la configuration de votre serveur pourra
- s'avérer nécessaire, par exemple l'ajout du drapeau
- <code>[PT]</code> si vous utilisez les modules
- <module>mod_alias</module>, <module>mod_userdir</module>, etc... Un
- jeu de règles défini dans le contexte du serveur devra aussi être
- adapté pour être utilisé dans un contexte <code>.htaccess</code>.
- Efforcez-vous toujours de bien comprendre l'effet produit par un jeu
- de règles avant de l'utiliser, ce qui pourra vous éviter bien des
- problèmes.</note>
-
- </summary>
-<seealso><a href="../mod/mod_rewrite.html">Documentation du module</a></seealso>
-<seealso><a href="intro.html">Introduction à mod_rewrite</a></seealso>
-<seealso><a href="rewrite_guide_advanced.html">Guide de réécriture
-avancé - exemples utiles avancés</a></seealso>
-<seealso><a href="tech.html">Détails techniques</a></seealso>
-
-
-<section id="canonicalurl">
-
-<title>URLs canoniques</title>
-
-<dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Sur certains serveurs web, une ressource peut être accessible
- depuis plusieurs URLs. On trouve en général des URLs canoniques
- (qui sont réellement utilisables et distribuables), mais aussi des
- URLs à usage interne, ou celles qui ne sont que des raccourcis,
- etc... On souhaite que, quelle que soit l'URL que l'utilisateur
- a fournie avec sa requête, il ne doit en voir en fin de compte
- que la forme canonique.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On effectue une redirection HTTP externe pour toutes les URLs
- non canoniques afin de les rendre compréhensibles au navigateur
- et ceci pour toutes les requêtes sous-jacentes. Dans l'exemple de
- jeux de règles ci-dessous, <code>/~user</code> est remplacé par
- l'expression canonique <code>/u/user</code>, et une éventuelle
- absence du slash à la fin de <code>/u/user</code> est corrigée.</p>
-
-<example><pre>
-RewriteRule ^/<strong>~</strong>([^/]+)/?(.*) /<strong>u</strong>/$1/$2 [<strong>R</strong>]
-RewriteRule ^/u/(<strong>[^/]+</strong>)$ /$1/$2<strong>/</strong> [<strong>R</strong>]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
-<section id="canonicalhost"><title>Noms d'hôtes canoniques</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>Le but de cette règle est de préférer l'utilisation d'un nom
- d'hôte particulier par rapport à d'autres noms d'hôte utilisables
- pour atteindre le même site. Par exemple, si vous voulez
- utiliser <strong>www.example.com</strong> à la place de
- <strong>example.com</strong>, vous devez utiliser une solution
- de ce style.</dd>
-
- <dt>Solution :</dt>
-
- <dd>
-<p>Pour les sites écoutant sur un port autre que 80:</p>
-<example><pre>
-RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
-RewriteCond %{HTTP_HOST} !^$
-RewriteCond %{SERVER_PORT} !^80$
-RewriteRule ^/?(.*) http://www.example.com:%{SERVER_PORT}/$1
-[L,R,NE]
-</pre></example>
-
-<p>Et pour un site écoutant sur le port 80</p>
-<example><pre>
-RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
-RewriteCond %{HTTP_HOST} !^$
-RewriteRule ^/?(.*) http://www.example.com/$1 [L,R,NE]
-</pre></example>
- <p>
- Si vous souhaitez que cette règle s'applique à tous les noms de
- domaine - en d'autres termes, si vous voulez rediriger
- <strong>example.com</strong> vers
- <strong>www.example.com</strong> pour toutes les valeurs
- possibles de <strong>example.com</strong>, vous pouvez utiliser
- le jeu de règles suivants :</p>
-
-<example><pre>
-RewriteCond %{HTTP_HOST} !^www\. [NC]
-RewriteCond %{HTTP_HOST} !^$
-RewriteRule ^/?(.*) http://www.%{HTTP_HOST}/$1 [L,R,NE]
-</pre></example>
- <p>
- Vous pouvez utiliser ce jeu de règles aussi bien dans le fichier
- de configuration de votre serveur principal que dans un fichier
- <code>.htaccess</code> placé dans le répertoire défini par la
- directive <directive
- module="core">DocumentRoot</directive> du serveur.</p>
- </dd>
- </dl>
-
- </section>
-
- <section id="moveddocroot">
-
- <title><code>DocumentRoot</code>déplacé</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
-<p>En général, la directive <directive
-module="core">DocumentRoot</directive> correspond directement à l'URL
-"<code>/</code>" du serveur web. Mais souvent, les données qui s'y
-trouvent ne sont pas de la première priorité. Par exemple, il peut être
-intéressant, pour les visiteurs qui entrent sur le site pour la première
-fois, d'être redirigés vers un sous-répertoire particulier
-<code>/a-propos-de/</code>. Pour ce faire, on peut utiliser le jeu de
-règles suivant :</p>
-</dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On redirige l'URL <code>/</code> vers
- <code>/a-propos-de/</code>:
- </p>
-
-<example><pre>
-RewriteEngine on
-RewriteRule <strong>^/$</strong> /a-propos-de/ [<strong>R</strong>]
-</pre></example>
-
- <p>Notez que le même effet peut être obtenu à l'aide de la directive
- <directive module="mod_alias">RedirectMatch</directive> :</p>
-
-<example>
-RedirectMatch ^/$ http://example.com/apropos/
-</example>
-<p>Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres
-termes, il réécrit une requête pour <code>http://example.com/</code>,
-mais ne réécrira pas une requête pour
-<code>http://example.com/page.html</code>. En fait, si vous avez modifié
-la racine de vos documents - c'est à dire si tous vos contenus se
-trouvent dans ce sous-répertoire, il vaut mieux simplement modifier
-votre directive <directive module="core">DocumentRoot</directive> que de
-procéder à une réécriture d'URLs.</p>
-</dd>
-</dl>
-
- </section>
-
- <section id="trailingslash">
-
- <title>Problème du slash de fin</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd><p>La plupart des problèmes de "slash de fin" peuvent être
- résolus grâce aux techniques décrites dans ce <a
- href="http://httpd.apache.org/docs/misc/FAQ-E.html#set-servername">sujet
- de la FAQ</a>. Cependant, dans certaines situations où l'absence de slash de fin
- peut rendre une URL inopérante, l'utilisation de
- mod_rewrite s'avère nécessaire. Le cas peut se présenter, par exemple,
- après une série complexe de règles de réécriture.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>La solution à ce problème subtil consiste à laisser le
- serveur ajouter le slash de fin automatiquement. Pour y
- parvenir, il faut utiliser une redirection externe, afin que
- le navigateur demande correctement les images sous-jacentes,
- etc... Une réécriture en interne ne fonctionnerait que pour la
- page du répertoire, mais échouerait pour toute image incluse
- dans cette page via des liens relatifs, car le navigateur
- demanderait un objet inséré. Par exemple, une requête pour
- <code>image.gif</code> dans <code>/~quux/foo/index.html</code>
- deviendrait <code>/~quux/image.gif</code> sans la redirection
- externe !</p>
-
- <p>Pour y parvenir, on peut utiliser des règles de ce style :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteBase /~quux/
-RewriteRule ^foo<strong>$</strong> foo<strong>/</strong> [<strong>R</strong>]
-</pre></example>
-
- <p>Vous pouvez aussi ajouter ce qui suit dans un fichier
- <code>.htaccess</code> situé dans le répertoire contenant la
- ressource. Notez cependant que cela augmente la charge du processeur.</p>
-
-<example><pre>
-RewriteEngine on
-RewriteBase /~quux/
-RewriteCond %{REQUEST_FILENAME} <strong>-d</strong>
-RewriteRule ^(.+<strong>[^/]</strong>)$ $1<strong>/</strong> [R]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="movehomedirs">
-
- <title>Déplacement des répertoires home vers un autre serveur</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>De nombreux webmasters ont demandé comment résoudre le
- problème suivant : ils voudraient tout simplement rediriger
- les répertoires home d'un serveur web vers un autre serveur
- web. Cette situation se présente en général lorsqu'on installe
- un nouveau serveur web destiné à terme à en remplacer un autre
- plus ancien.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Avec <module>mod_rewrite</module>, la solution est
- évidente. Sur l'ancien serveur web, on redirige simplement
- toutes les URLs du style <code>/~user/chemin</code> vers
- <code>http://nouveau-serveur/~user/chemin</code>.</p>
-
-<example><pre>
-RewriteEngine on
-RewriteRule ^/~(.+) http://<strong>nouveau-serveur</strong>/~$1 [R,L]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="multipledirs">
-
- <title>Recherche de pages dans plus d'un répertoire</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Le serveur web doit parfois rechercher des pages dans plus
- d'un répertoire. Dans ce cas, les vues multiples ou autres
- techniques similaires ne sont d'aucun secours.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On définit explicitement un jeu de règles qui recherche les
- fichiers dans les répertoires.</p>
-
-<example><pre>
-RewriteEngine on
-
-# on cherche tout d'abord dans dir1/...
-# ... et si on trouve, on est content et on arrête :
-RewriteCond %{DOCUMENT_ROOT}/<strong>dir1</strong>/%{REQUEST_URI} -f
-RewriteRule ^(.+) %{DOCUMENT_ROOT}/<strong>dir1</strong>/$1 [L]
-
-# on cherche ensuite dans dir2/...
-# ... et si on trouve, on est content et on arrête :
-RewriteCond %{DOCUMENT_ROOT}/<strong>dir2</strong>/%{REQUEST_URI} -f
-RewriteRule ^(.+) %{DOCUMENT_ROOT}/<strong>dir2</strong>/$1 [L]
-
-# sinon, on continue la recherche avec d'autres directives Alias
-# ou ScriptAlias, etc...
-RewriteRule ^(.+) - [PT]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="setenvvars">
-
- <title>Définir des variables d'environnement en fonction de
- certaines parties de l'URL</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment conserver des informations
- d'état d'une requête à l'autre et utiliser l'URL pour les
- encoder, sans utiliser d'encapsulateur CGI
- pour toutes les pages pour seulement supprimer ces
- informations.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On utilise une règle de réécriture pour supprimer
- l'information d'état et l'enregistrer dans une variable
- d'environnement dont on pourra plus tard extraire la valeur
- dans XSSI ou CGI. De cette façon, une URL telle que
- <code>/foo/S=java/bar/</code> sera traduite en
- <code>/foo/bar/</code> et la variable d'environnement
- <code>STATUS</code> aura pour valeur "java".</p>
-
-<example><pre>
-RewriteEngine on
-RewriteRule ^(.*)/<strong>S=([^/]+)</strong>/(.*) $1/$3 [E=<strong>STATUS:$2</strong>]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="uservhosts">
-
- <title>Hôtes virtuels basés sur l'utilisateur</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Supposons que vous vouliez atteindre la page d'accueil des
- utilisateurs sur une même machine au moyen de l'URL
- <code>www.<strong>nom-utilisateur</strong>.hôte.domaine.com</code>,
- en vous basant
- seulement sur les enregistrements DNS de type A, et ceci sans qu'aucun
- hôte virtuel ne soit installé sur cette machine.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Dans le cas des requêtes HTTP/1.0, il n'y a pas de solution
- ; par contre, avec une requête HTTP/1.1 qui contient un
- en-tête HTTP Host:, on peut utiliser le jeu de règles suivant
- pour réécrire en interne
- <code>http://www.nom-utilisateur.hôte.com/chemin</code> vers
- <code>/home/nom-utilisateur/chemin</code> :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteCond %{<strong>HTTP_HOST</strong>} ^www\.<strong>([^.]+)</strong>\.host\.com$
-RewriteRule ^(.*) /home/<strong>%1</strong>$1
-</pre></example>
-<p>Les parenthèses utilisées dans une directive <directive
-module="mod_rewrite">RewriteCond</directive> sont capturées dans les
-références arrières <code>%1</code>, <code>%2</code>, etc..., alors que
-les parenthèses utilisées dans une directive <directive
-module="mod_rewrite">RewriteRule</directive> sont capturées dans les
-références arrières <code>$1</code>, <code>$2</code>, etc...</p>
- </dd>
- </dl>
-
- </section>
-
- <section id="redirecthome">
-
- <title>Redirection des répertoires d'accueil pour les étrangers</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>On veut rediriger les URLs des répertoires d'accueil vers
- un autre serveur <code>www.quelque-part.com</code> lorsque
- l'utilisateur demandeur n'appartient pas au domaine local
- <code>notre-domaine.com</code>. On rencontre parfois cette
- situation dans un contexte d'hôtes virtuels.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Juste une condition de réécriture :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteCond %{REMOTE_HOST} <strong>!^.+\.notre-domaine\.com$</strong>
-RewriteRule ^(/~.+) http://www.quelque-part.com/$1 [R,L]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="redirectanchors">
-
- <title>Redirection des ancrages</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Par défaut, la redirection vers un ancrage HTML ne fonctionne
- pas, car mod_rewrite échappe le caractère <code>#</code> en le
- transformant en <code>%23</code>, ce qui rend la redirection
- inopérante.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On utilise le drapeau <code>[NE]</code> dans la règle
- <code>RewriteRule</code>. NE signifie "No Escape".
- </p>
- </dd>
- </dl>
-
- </section>
-
- <section id="time-dependent">
-
- <title>Réécriture dépendant de l'heure</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Lorsqu'il s'agit de distribuer des contenus dont la nature
- dépend de l'heure, de nombreux webmasters utilisent encore des
- scripts CGI qui redirigent par exemple vers des pages
- spécifiques. Comment peut-on y parvenir à tenir compte de
- l'heure à l'aide de <module>mod_rewrite</module> ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Il existe de nombreuses variables nommées
- <code>TIME_xxx</code> utilisables dans les conditions de
- réécriture. Utilisées en conjonction avec les modèles de
- comparaison lexicographique spéciaux <code><STRING</code>,
- <code>>STRING</code> et <code>=STRING</code>, elles
- permettent d'effectuer des redirections dépendant de
- l'heure :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
-RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
-RewriteRule ^foo\.html$ foo.jour.html
-RewriteRule ^foo\.html$ foo.nuit.html
-</pre></example>
-
- <p>Avec cet exemple, l'URL <code>foo.html</code> renvoie
- le contenu de <code>foo.jour.html</code> durant le
- créneau horaire <code>07:00-19:00</code>, et le contenu de
- <code>foo.nuit.html</code> le reste du temps. Agréable
- fonctionnalité pour une page d'accueil...</p>
- </dd>
- </dl>
-
- </section>
-
- <section id="backward-compatibility">
-
- <title>Compatibilité ascendante pour une migration de YYYY vers
- XXXX</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment conférer une compatibilité ascendante aux URLs
- (existant encore virtuellement) après avoir migré
- <code>document.YYYY</code> vers <code>document.XXXX</code>,
- c'est à dire après avoir par exemple traduit un lot de
- fichiers <code>.html</code> en fichiers <code>.phtml</code>
- ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On réécrit simplement le nom du fichier en son nom
- de base et vérifie s'il existe aussi avec la nouvelle
- extension. Si c'est le cas, on utilise ce nom, sinon on
- réécrit l'URL sous sa forme originale.</p>
-
-
-<example><pre>
-# jeu de règles assurant une compatibilité ascendante en réécrivant
-# document.html en document.phtml si et seulement si document.phtml
-# existe et document.html n'existe plus
-RewriteEngine on
-RewriteBase /~quux/
-# réécriture du fichier en son nom de base,
-# mais garde en mémoire le fait qu'il s'agit
-# d'un fichier html
-RewriteRule ^(.*)\.html$ $1 [C,E=WasHTML:yes]
-# réécrit vers document.phtml s'il existe
-# Note : il s'agit d'un exemple de niveau répertoire, si bien que
-# %{REQUEST_FILENAME} contient le chemin complet du système de fichier
-# tel qu'il a été construit par le serveur.
-RewriteCond %{REQUEST_FILENAME}.phtml -f
-RewriteRule ^(.*)$ $1.phtml [S=1]
-# sinon, restauration du nom de fichier complet original
-RewriteCond %{ENV:WasHTML} ^yes$
-RewriteRule ^(.*)$ $1.html
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="old-to-new">
-
- <title>De l'ancien au nouveau (en interne)</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Supposons que nous ayons récemment renommé la page
- <code>foo.html</code> en <code>bar.html</code>, et voulions
- maintenant que l'ancienne URL soit toujours valide à des fins
- de compatibilité ascendante. En fait, on voudrait que le
- changement de nom soit transparent aux utilisateurs de
- l'ancienne URL.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On réécrit l'ancienne URL en interne vers la nouvelle via
- la règle suivante :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteBase /~quux/
-RewriteRule ^<strong>foo</strong>\.html$ <strong>bar</strong>.html
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="old-to-new-extern">
-
- <title>De l'ancien au nouveau (en externe)</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Supposons toujours que nous ayons récemment renommé la page
- <code>foo.html</code> en <code>bar.html</code>, et voulions
- maintenant que l'ancienne URL soit toujours valide à des fins
- de compatibilité ascendante. Par contre, nous voulons cette
- fois que les utilisateurs de l'ancienne URL soient redirigés
- vers la nouvelle, c'est à dire que l'adresse tapée
- dans leur navigateur doit aussi être modifiée.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On force une redirection HTTP vers la nouvelle URL, ce qui
- entraîne une modification de celle du navigateur et aussi de ce
- que voit l'utilisateur :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteBase /~quux/
-RewriteRule ^<strong>foo</strong>\.html$ <strong>bar</strong>.html [<strong>R</strong>]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="static-to-dynamic">
-
- <title>De statique à dynamique</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment transformer une page statique <code>foo.html</code>
- en sa variante dynamique <code>foo.cgi</code> de manière
- transparente, c'est à dire sans en avertir le
- navigateur/utilisateur.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On réécrit simplement l'URL en script CGI et force le
- gestionnaire de contenu à <strong>cgi-script</strong> de façon
- à ce que le script s'exécute en tant que programme CGI.
- Ainsi, une requête vers <code>/~quux/foo.html</code> conduit
- en interne à l'invocation de
- <code>/~quux/foo.cgi</code>.</p>
-
-<example><pre>
-RewriteEngine on
-RewriteBase /~quux/
-RewriteRule ^foo\.<strong>html</strong>$ foo.<strong>cgi</strong> [H=<strong>cgi-script</strong>]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="blocking-of-robots">
-
- <title>Blocage des robots</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment empêcher un robot vraiment gênant de collecter les
- pages d'une partie spécifique du site web ? Un fichier
- <code>/robots.txt</code> comportant les entrées du "Protocole
- d'Exclusion des Robots" ne suffit généralement pas à en venir
- à bout.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On utilise un jeu de règles qui interdit les URLs de la
- partie du site web concernée <code>/~quux/foo/arc/</code>
- (peut-être une partie du serveur avec une arborescence très
- développée à travers laquelle le parcours du
- robot induirait une charge importante pour le serveur). Nous
- devons nous assurer de n'interdire l'accès qu'à ce robot
- particulier, c'est à dire qu'il ne suffit pas d'interdire
- l'accès à l'hôte sur lequel le robot fonctionne, ce qui
- bloquerait aussi les utilisateurs de cet hôte. Pour y
- parvenir, on tient aussi compte des informations contenues
- dans l'en-tête HTTP User-Agent.</p>
-
-<example><pre>
-RewriteCond %{HTTP_USER_AGENT} ^<strong>NameOfBadRobot</strong>.*
-RewriteCond %{REMOTE_ADDR} ^<strong>123\.45\.67\.[8-9]</strong>$
-RewriteRule ^<strong>/~quux/foo/arc/</strong>.+ - [<strong>F</strong>]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="blocked-inline-images">
-
- <title>Blocage du référencement à chaud (Hotlinking) d'images</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Cette technique vous permet d'interdire à d'autres sites
- d'inclure directement vos images dans leurs pages. On fait
- souvent référence à cette pratique sous le nom de
- référencement à chaud (Hotlinking) qui entraîne l'utilisation
- de votre bande passante pour servir des contenus faisant
- partie du site de quelqu'un d'autre.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Cette technique repose sur la valeur de la variable
- optionnelle <code>HTTP_REFERER</code>. Certaines personnes
- pourront donc contourner cette limitation. Pour la plupart des
- utilisateurs cependant, la requête échouera, en ce sens que
- l'image ne sera pas affichée depuis le site tiers.</p>
- <p>Il y a plusieurs manières de gérer cette situation.</p>
-
- <p>Dans le premier exemple, nous rejetons tout simplement la
- requête si elle ne provenait pas d'une page appartenant à notre
- site. Pour les besoins de cet exemple, nous supposons que le nom
- de votre site est <code>www.example.com</code>.</p>
-
-<example><pre>
-RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
-RewriteCond %{HTTP_REFERER} !www.example.com [NC]
-RewriteRule <strong>\.(gif|jpg|png)$</strong> - [F,NC]
-</pre></example>
-
- <p>Dans le second exemple, plutôt que de rejeter la requête,
- nous affichons une autre image à la place.</p>
-
-<example><pre>
-RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
-RewriteCond %{HTTP_REFERER} !www.example.com [NC]
-RewriteRule <strong>\.(gif|jpg|png)$</strong> /images/go-away.png [R,NC]
-</pre></example>
-
- <p>Dans le troisième exemple, nous redirigeons la requête vers
- une image appartenant à un site tiers.</p>
-
-
-<example><pre>
-RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
-RewriteCond %{HTTP_REFERER} !www.example.com [NC]
-RewriteRule <strong>\.(gif|jpg|png)$</strong> http://other.site.com/image.gif [R,NC]
-</pre></example>
- <p>De tous ces exemples, les deux derniers semblent les plus
- efficaces pour faire en sorte que les gens arrêtent de
- référencer vos images à chaud, car il ne verront pas les images
- qu'ils s'attendent à voir.</p>
-
- </dd>
- </dl>
-
- </section>
-
- <section id="proxy-deny">
-
- <title>Interdiction du mandataire</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment interdire l'utilisation du mandataire d'Apache à un
- certain hôte, ou même à un utilisateur d'un certain hôte ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Nous devons tout d'abord nous assurer que
- <module>mod_rewrite</module> se situe en dessous (!) de
- <module>mod_proxy</module> dans le fichier de configuration
- lors de la compilation du serveur web Apache. De cette façon,
- il est appelé <em>avant</em> <module>mod_proxy</module>. Nous
- pouvons alors utiliser la règle suivante pour une interdiction
- concernant un hôte...</p>
-
-<example><pre>
-RewriteCond %{REMOTE_HOST} <strong>^mauvais-hôte\.mon-domaine\.com$</strong>
-RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
-</pre></example>
-
- <p>...et celle-ci pour une interdiction concernant un
- utilisateur d'un certain hôte :</p>
-
-<example><pre>
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}
-<strong>^mauvais-sujet@mauvais-hôte\.mon-domaine\.com$</strong>
-RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="external-rewriting">
-
- <title>Moteur de réécriture externe</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Une question de la Faq : comment résoudre le problème
- FOO/BAR/QUUX/etc. ? <module>mod_rewrite</module> ne semble pas
- devoir y apporter de solution...</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Utiliser une <directive module="mod_rewrite"
- >RewriteMap</directive> ou table de réécriture externe, c'est
- à dire un programme qui agit de la même façon qu'une
- <directive module="mod_rewrite">RewriteMap</directive>. Il
- doit être lancé une fois au démarrage d'Apache, recevoir les
- URLs des requêtes sur <code>STDIN</code>, et restituer l'URL
- résultante (en général réécrite) sur <code>STDOUT</code> (dans
- cet ordre !).</p>
-
-<example><pre>
-RewriteEngine on
-RewriteMap quux-table <strong>prg:</strong>/chemin/vers/table.quux.pl
-RewriteRule ^/~quux/(.*)$ /~quux/<strong>${quux-table:$1}</strong>
-</pre></example>
-
-<example><pre>
-#!/chemin/vers/perl
-
-# désactive la mise en tampon des entrées/sorties, qui risque
-# de provoquer des bouclages infinis pour le serveur Apache
-$| = 1;
-
-# lit les URLs (une par ligne) depuis stdin et
-# génère l'URL transformée sur stdout
-
-# read URLs one per line from stdin and
-# generate substitution URL on stdout
-while (<>) {
- s|^foo/|bar/|;
- print $_;
-}
-</pre></example>
-
- <p>Ceci n'est qu'un exemple de démonstration qui ne fait que
- réécrire les URLs du style <code>/~quux/foo/...</code> vers
- <code>/~quux/bar/...</code>. En fait, vous pouvez programmer
- la substitution que vous voulez. Notez cependant que si de
- tels programmes peuvent aussi être <strong>utilisés</strong>
- par un utilisateur standard, seul l'administrateur du système
- peut les <strong>écrire</strong>.</p>
- </dd>
- </dl>
-
- </section>
-
-</manualpage>
-
+++ /dev/null
-<?xml version="1.0" encoding="ISO-8859-1" ?>
-<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
-<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision : 805049 -->
-<!-- French translation : Lucien GENTIS -->
-<!-- Reviewed by : Vincent Deffontaines -->
-
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<manualpage metafile="rewrite_guide_advanced.xml.meta">
- <parentdocument href="./">Rewrite</parentdocument>
-
- <title>Guide de réécriture des URLs - Sujets avancés</title>
-
- <summary>
-
- <p>Ce document complémente la
- <a href="../mod/mod_rewrite.html">documentation de référence</a> du
- module <module>mod_rewrite</module>. Il décrit les différentes
- manières d'utiliser le module d'Apache <module>mod_rewrite</module>
- pour résoudre les problèmes d'URLs typiques auxquels sont souvent
- confrontés les webmasters. Nous fournissons une description
- détaillée de la résolution de chaque problème par la configuration
- d'un jeu de règles de réécriture.</p>
-
- <note type="warning">ATTENTION: il pourra s'avérer nécessaire de
- modifier les exemples en fonction de la
- configuration de votre serveur, par exemple en ajoutant le drapeau
- <code>[PT]</code> si les modules <module>mod_alias</module> et
- <module>mod_userdir</module> sont utilisés, etc... Les jeux de
- règles devront également être adaptés pour passer d'un contexte de
- serveur à un contexte de répertoire (fichiers
- <code>.htaccess</code>). Essayez de toujours bien comprendre ce que
- fait un jeu de règles avant de l'utiliser, ce qui pourra vous éviter
- bien des problèmes.</note>
-
- </summary>
-<seealso><a href="../mod/mod_rewrite.html">Documentation du
-module</a></seealso>
-<seealso><a href="intro.html">Introduction à
-mod_rewrite</a></seealso>
-<seealso><a href="rewrite_guide.html">Guide de réécriture - exemples
-utiles</a></seealso>
-<seealso><a href="tech.html">Détails techniques</a></seealso>
-
-
- <section id="cluster">
-
- <title>Accès à une grappe de serveurs via un espace d'adressage
- compatible</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment créer un espace d'adressage homogène et compatible
- avec
- tous les serveurs WWW d'une grappe de serveurs d'un intranet ?
- C'est à dire que toutes les URLs (par définition
- locales à un
- serveur et dépendant donc de celui-ci) deviennent
- véritablement <em>indépendantes</em> du serveur ! Nous voulons
- disposer, pour accéder à l'espace de nommage WWW, d'un seul
- espace d'adressage compatible : aucune URL ne
- doit inclure d'information quelconque à propos du serveur
- cible physique. La grappe de serveurs doit elle-même nous
- diriger automatiquement vers le bon serveur cible physique,
- selon les besoins, et ceci de manière transparente.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Tout d'abord, la connaissance des serveurs cibles est issue
- de tables de correspondances externes (distribuées) qui
- contiennent des informations sur la localisation de nos
- utilisateurs, groupes et entités. Elles se présentent sous la
- forme :</p>
-
-<example><pre>
-utilisateur1 serveur_utilisateur1
-utilisateur2 serveur_utilisateur2
-: :
-</pre></example>
-
- <p>On les enregistre sous forme de fichiers
- <code>map.xxx-vers-serveur</code>. On doit ensuite faire
- rediriger à tous les serveurs les URLs de la forme :</p>
-
-<example><pre>
-/u/utilisateur/chemin
-/g/groupe/chemin
-/e/entité/chemin
-</pre></example>
-
- <p>vers</p>
-
-<example><pre>
-http://serveur-physique/u/utilisateur/chemin
-http://serveur-physique/g/groupe/chemin
-http://serveur-physique/e/entité/chemin
-</pre></example>
-
- <p>si il n'est pas nécessaire que chaque chemin d'URL être valide sur chaque
- serveur. Le jeu
- de règles suivant le fait pour nous à l'aide des fichiers de
- correspondance (en supposant que serveur0 soit un serveur par
- défaut qui sera choisi si l'utilisateur ne possède aucune
- entrée dans la table) :</p>
-
-<example><pre>
-RewriteEngine on
-
-RewriteMap utilisateur-vers-serveur txt:/chemin/vers/map.utilisateur-vers-serveur
-RewriteMap groupe-vers-serveur txt:/chemin/vers/map.groupe-vers-serveur
-RewriteMap entité-vers-serveur txt:/chemin/vers/map.entité-vers-serveur
-
-RewriteRule ^/u/<strong>([^/]+)</strong>/?(.*)
-http://<strong>${utilisateur-vers-serveur:$1|serveur0}</strong>/u/$1/$2
-RewriteRule ^/g/<strong>([^/]+)</strong>/?(.*)
-http://<strong>${groupe-vers-serveur:$1|serveur0}</strong>/g/$1/$2
-RewriteRule ^/e/<strong>([^/]+)</strong>/?(.*)
-http://<strong>${entité-vers-serveur:$1|serveur0}</strong>/e/$1/$2
-
-RewriteRule ^/([uge])/([^/]+)/?$ /$1/$2/.www/
-RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="structuredhomedirs">
-
- <title>Répertoires utilisateurs structurés</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Certains sites possédant des milliers d'utilisateurs
- organisent les répertoires home de manière
- structurée, <em>c'est à dire</em> que chaque répertoire home
- se situe dans un sous-répertoire dont le nom commence (par
- exemple) par le premier caractère du nom de l'utilisateur.
- Ainsi, <code>/~foo/chemin</code> est dans
- <code>/home/<strong>f</strong>/foo/.www/chemin</code>, tandis
- que <code>/~bar/chemin</code> est dans
- <code>/home/<strong>b</strong>/bar/.www/chemin</code>.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Le jeu de règles suivant permet de développer les URLs avec
- tilde selon la représentation ci-dessus.</p>
-
-<example><pre>
-RewriteEngine on
-RewriteRule ^/~(<strong>([a-z])</strong>[a-z0-9]+)(.*) /home/<strong>$2</strong>/$1/.www$3
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="filereorg">
-
- <title>Réorganisation du système de fichiers</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Voici un cas d'espèce : une application très efficace qui
- fait un usage intensif de règles <code>RewriteRule</code>
- dans le contexte du répertoire pour présenter un aspect
- compréhensible sur le Web sans modifier la structure des
- données.
- Les coulisses de l'affaire : <strong><em>net.sw</em></strong>
- rassemble mes archives de paquetages de logiciels Unix
- librement accessibles, que j'ai commencé à collectionner en
- 1992. Pour moi, c'est un passe-temps, mais aussi un travail,
- car alors que j'étudie la science informatique, j'ai aussi
- travaillé depuis de nombreuses années comme administrateur
- système et réseau à mes heures perdues. Chaque semaine j'ai
- besoin de tel ou tel logiciel, et j'ai donc créé une
- arborescence très ramifiée de répertoires où je stocke les
- paquetages :</p>
-
-<example><pre>
-drwxrwxr-x 2 netsw users 512 Aug 3 18:39 Audio/
-drwxrwxr-x 2 netsw users 512 Jul 9 14:37 Benchmark/
-drwxrwxr-x 12 netsw users 512 Jul 9 00:34 Crypto/
-drwxrwxr-x 5 netsw users 512 Jul 9 00:41 Database/
-drwxrwxr-x 4 netsw users 512 Jul 30 19:25 Dicts/
-drwxrwxr-x 10 netsw users 512 Jul 9 01:54 Graphic/
-drwxrwxr-x 5 netsw users 512 Jul 9 01:58 Hackers/
-drwxrwxr-x 8 netsw users 512 Jul 9 03:19 InfoSys/
-drwxrwxr-x 3 netsw users 512 Jul 9 03:21 Math/
-drwxrwxr-x 3 netsw users 512 Jul 9 03:24 Misc/
-drwxrwxr-x 9 netsw users 512 Aug 1 16:33 Network/
-drwxrwxr-x 2 netsw users 512 Jul 9 05:53 Office/
-drwxrwxr-x 7 netsw users 512 Jul 9 09:24 SoftEng/
-drwxrwxr-x 7 netsw users 512 Jul 9 12:17 System/
-drwxrwxr-x 12 netsw users 512 Aug 3 20:15 Typesetting/
-drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/
-</pre></example>
-
- <p>J'ai décidé en 1996 de rendre cette archive disponible pour
- le monde via une interface web agréable. "Agréable" signifie
- que je voulais vous offrir une interface où vous pourriez
- naviguer directement à travers la hiérarchie des archives.
- Mais "agréable" signifie aussi que je ne voulais rien changer
- dans cette hiérarchie - même pas en ajoutant queques scripts
- CGI à son sommet. Pourquoi ? Parceque j'avais prévu de rendre
- ultérieurement la structure ci-dessus accessible aussi via
- FTP, et je ne voulais pas voir de fichiers CGI ou Web à ce
- niveau.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>La solution comporte deux parties : la première consiste en
- un ensemble de scripts CGI qui créent toutes les pages à tous
- les niveaux de répertoires à la volée. Je les ai placés dans
- <code>/e/netsw/.www/</code> comme suit :</p>
-
-<example><pre>
--rw-r--r-- 1 netsw users 1318 Aug 1 18:10 .wwwacl
-drwxr-xr-x 18 netsw users 512 Aug 5 15:51 DATA/
--rw-rw-rw- 1 netsw users 372982 Aug 5 16:35 LOGFILE
--rw-r--r-- 1 netsw users 659 Aug 4 09:27 TODO
--rw-r--r-- 1 netsw users 5697 Aug 1 18:01 netsw-about.html
--rwxr-xr-x 1 netsw users 579 Aug 2 10:33 netsw-access.pl
--rwxr-xr-x 1 netsw users 1532 Aug 1 17:35 netsw-changes.cgi
--rwxr-xr-x 1 netsw users 2866 Aug 5 14:49 netsw-home.cgi
-drwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/
--rwxr-xr-x 1 netsw users 24050 Aug 5 15:49 netsw-lsdir.cgi
--rwxr-xr-x 1 netsw users 1589 Aug 3 18:43 netsw-search.cgi
--rwxr-xr-x 1 netsw users 1885 Aug 1 17:41 netsw-tree.cgi
--rw-r--r-- 1 netsw users 234 Jul 30 16:35 netsw-unlimit.lst
-</pre></example>
-
- <p>Le sous-répertoire <code>DATA/</code> contient la structure
- de répertoires proprement dite mentionnée plus haut, <em>c'est
- à dire</em> les véritables ressources
- <strong><em>net.sw</em></strong> et est mis à jour
- automatiquement via <code>rdist</code> à intervalles de temps
- réguliers. Reste la seconde partie du problème : comment
- relier ces deux structures selon une arborescence d'URL
- facile d'accès ? Il nous faut cacher le répertoire
- <code>DATA/</code> à l'utilisateur durant l'exécution des
- scripts CGI appropriés aux différentes URLs. Voici comment :
- tout d'abord, j'ajoute ces deux règles dans le fichier de
- configuration du répertoire racine <directive
- module="core">DocumentRoot</directive> du serveur afin de
- réécrire le chemin d'URL public <code>/net.sw/</code> vers le
- chemin interne <code>/e/netsw</code> :</p>
-
-<example><pre>
-RewriteRule ^net.sw$ net.sw/ [R]
-RewriteRule ^net.sw/(.*)$ e/netsw/$1
-</pre></example>
-
- <p>La première règle concerne les requêtes qui ne comportent
- pas de slash de fin ! C'est la seconde règle qui fait le
- véritable travail. Et maintenant vient la super configuration
- qui se trouve dans le fichier de configuration de répertoire
- <code>/e/netsw/.www/.wwwacl</code> :</p>
-
-<example><pre>
-Options ExecCGI FollowSymLinks Includes MultiViews
-
-RewriteEngine on
-
-# l'accès s'effectue via le préfixe /net.sw/
-RewriteBase /net.sw/
-
-# tout d'abord, on réécrit le répertoire racine vers
-# le script CGI qui lui est associé
-RewriteRule ^$ netsw-home.cgi [L]
-RewriteRule ^index\.html$ netsw-home.cgi [L]
-
-# on supprime les sous-répertoires lorsque
-# le navigateur nous atteint depuis des pages de répertoire
-RewriteRule ^.+/(netsw-[^/]+/.+)$ $1 [L]
-
-# on stoppe maintenant la réécriture pour les fichiers locaux
-RewriteRule ^netsw-home\.cgi.* - [L]
-RewriteRule ^netsw-changes\.cgi.* - [L]
-RewriteRule ^netsw-search\.cgi.* - [L]
-RewriteRule ^netsw-tree\.cgi$ - [L]
-RewriteRule ^netsw-about\.html$ - [L]
-RewriteRule ^netsw-img/.*$ - [L]
-
-# ce qui reste est un sous-répertoire qui peut être traité
-# par un autre script CGI
-RewriteRule !^netsw-lsdir\.cgi.* - [C]
-RewriteRule (.*) netsw-lsdir.cgi/$1
-</pre></example>
-
- <p>Quelques indices pour l'interprétation :</p>
-
- <ol>
- <li>Remarquez le drapeau <code>L</code> (last) et l'absence
- de chaîne de substitution ('<code>-</code>') dans la
- quatrième partie.</li>
-
- <li>Remarquez le caractère <code>!</code> (not) et le
- drapeau <code>C</code> (chain) dans la première règle de la
- dernière partie.</li>
-
- <li>Remarquez le modèle qui correspond à tout dans la
- dernière règle.</li>
- </ol>
- </dd>
- </dl>
-
- </section>
-
- <section id="redirect404">
-
- <title>Rediriger les URLs erronées vers un autre serveur Web</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Une question typique de la FAQ à propos de la réécriture
- revient souvent : comment rediriger vers un serveur B les
- requêtes qui échouent sur un serveur A ? On s'acquitte en
- général de cette tâche via des scripts CGI <directive
- module="core">ErrorDocument</directive> en Perl, mais il
- existe aussi une solution avec <module>mod_rewrite</module>.
- Notez cependant que les performances sont moindres qu'avec
- l'utilisation d'un script CGI <directive
- module="core">ErrorDocument</directive> !</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>La première solution possède des performances supérieures
- mais moins de souplesse, et est moins sure :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteCond %{DOCUMENT_ROOT/%{REQUEST_URI} <strong>!-f</strong>
-RewriteRule ^(.+) http://<strong>serveurB</strong>.dom/$1
-</pre></example>
-
- <p>Le problème réside dans le fait que seules les pages
- situées dans la racine <directive
- module="core">DocumentRoot</directive> seront redirigées. Mais
- même si vous pouvez ajouter des conditions supplémentaires (par
- exemple pour traiter aussi les répertoires home, etc...), il
- existe une meilleure solution :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteCond %{REQUEST_URI} <strong>!-U</strong>
-RewriteRule ^(.+) http://<strong>serveurB</strong>.dom/$1
-</pre></example>
-reprendre ici
- <p>On utilise ici la fonctionnalité de prévision des URLs
- futures de <module>mod_rewrite</module>. Et cette solution
- fonctionne pour tous les types d'URLs et de manière sûre. Par
- contre, cette méthode a un impact sur les performances du
- serveur web, car chaque requête entraîne le traitement d'une
- sous-requête interne supplémentaire. Par conséquent, vous
- pouvez l'utiliser si votre serveur web s'exécute sur un CPU
- puissant. Dans le cas d'une machine plus lente, utilisez la
- première approche, ou mieux, un script CGI <directive
- module="core">ErrorDocument</directive>.</p>
- </dd>
- </dl>
-
- </section>
-
- <section id="archive-access-multiplexer">
-
- <title>Multiplexeur d'accès aux archives</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Connaissez-vous la grande archive CPAN (Comprehensive Perl Archive
- Network) située à <a href="http://www.perl.com/CPAN"
- >http://www.perl.com/CPAN</a> ?
- CPAN redirige automatiquement les navigateurs vers un des
- nombreux serveurs FTP répartis à travers le monde
- (généralement un serveur assez proche du client) ; chaque
- serveur héberge l'intégralité d'un miroir CPAN. Il s'agit ni
- plus ni moins qu'un service d'accès FTP multiplexé. Alors que
- le fonctionnement de l'archive CPAN repose sur des scripts
- CGI, comment implémenter une approche similaire avec
- <module>mod_rewrite</module> ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Premièrement, remarquons que depuis la version 3.0.0,
- <module>mod_rewrite</module> accepte aussi le préfixe
- "<code>ftp:</code>" dans les redirections. Et deuxièmement,
- l'approximation de la localisation peut être effectuée par une
- table de correspondances <directive
- module="mod_rewrite">RewriteMap</directive>, en se basant sur
- la racine du domaine du client. Un jeu de règles chaînées
- astucieux nous permet d'utiliser cette racine du domaine comme
- clé de recherche dans notre table de correspondances de
- multiplexage.</p>
-
-<example><pre>
-RewriteEngine on
-RewriteMap multiplex txt:/chemin/vers/map.cxan
-RewriteRule ^/CxAN/(.*) %{REMOTE_HOST}::$1 [C]
-RewriteRule ^.+\.<strong>([a-zA-Z]+)</strong>::(.*)$
-${multiplex:<strong>$1</strong>|ftp.défaut.dom}$2 [R,L]
-</pre></example>
-
-<example><pre>
-##
-## map.cxan -- Multiplexing Map for CxAN%{DOCUMENT_ROOT/%{REQUEST_URI}
-##
-
-de ftp://ftp.cxan.de/CxAN/
-uk ftp://ftp.cxan.uk/CxAN/
-com ftp://ftp.cxan.com/CxAN/
- :
-##EOF##
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="browser-dependent-content">
-
- <title>Contenu dépendant du navigateur</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Il est parfois nécessaire, au moins pour les pages
- principales, de fournir un contenu optimum adapté à chaque
- type de navigateur, c'est à dire que l'on doit
- fournir une version pour les navigateurs courants, une version
- différente pour les navigateurs en mode texte du style de
- Lynx, et une autre pour les autres navigateurs.</p>
- </dd>
-
- <dt>Solution :</dt><!-- %{DOCUMENT_ROOT/%{REQUEST_URI} -->
-
- <dd>
- <p>On ne peut pas utiliser la négociation de contenu car les
- navigateurs ne fournissent pas leur type dans cette forme.
- Nous devons nous baser sur l'en-tête HTTP "User-Agent". La
- configuration ci-dessous effectue les actions suivantes : si
- l'en-tête HTTP "User-Agent" commence par "Mozilla/3", la page
- <code>foo.html</code> est réécrite en <code>foo.NS.html</code>
- et la réécriture s'arrête. Si le navigateur est "Lynx" ou
- "Mozilla" version 1 ou 2, la page
- <code>foo.html</code> est réécrite en
- <code>foo.20.html</code>. Tous les autres navigateurs
- reçoivent la page <code>foo.32.html</code>. Voici le jeu de
- règles :</p>
-
-<example><pre>
-RewriteCond %{HTTP_USER_AGENT} ^<strong>Mozilla/3</strong>.*
-RewriteRule ^foo\.html$ foo.<strong>NS</strong>.html [<strong>L</strong>]
-
-RewriteCond %{HTTP_USER_AGENT} ^<strong>Lynx/</strong>.* [OR]
-RewriteCond %{HTTP_USER_AGENT} ^<strong>Mozilla/[12]</strong>.*
-RewriteRule ^foo\.html$ foo.<strong>20</strong>.html [<strong>L</strong>]
-
-RewriteRule ^foo\.html$ foo.<strong>32</strong>.html [<strong>L</strong>]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="dynamic-mirror">
-
- <title>Miroir dynamique</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Supposons que nous voulions intégrer dans notre espace de
- nommage de belles pages web situées sur un serveur distant.
- Dans le cas d'un serveur FTP, nous aurions utilisé le
- programme <code>mirror</code> qui maintient vraiment une copie
- des données distantes mise à jour explicitement sur le serveur
- local. Pour un serveur web, nous pourrions utiliser le
- programme <code>webcopy</code> qui utilise le protocole HTTP.
- Ces deux techniques présentent cependant un
- inconvénient majeur : la copie locale n'est véritablement à
- jour qu'au moment où nous avons lancé le programme. Plutôt qu'
- un miroir statique devant être défini explicitement, il serait
- préférable d'avoir un miroir dynamique dont le contenu serait
- mis à jour automatiquement, à la demande, sur le(s) serveur(s)
- distant(s).</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Pour y parvenir, on fait
- correspondre la page web ou même l'ensemble du
- répertoire web distants à notre espace de nommage en utilisant
- la fonctionnalité <dfn>Mandataire</dfn> (drapeau
- <code>[P]</code> ou <code>[proxy]</code>) :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteBase /~quux/
-RewriteRule ^<strong>page-convoitée/</strong>(.*)$ <strong>http://www.tstimpreso.com/page-convoitée/</strong>$1 [<strong>P</strong>]
-</pre></example>
-
-<example><pre>
-RewriteEngine on
-RewriteBase /~quux/
-RewriteRule ^<strong>usa-news\.html</strong>$ <strong>http://www.quux-corp.com/news/index.html</strong> [<strong>P</strong>]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="reverse-dynamic-mirror">
-
- <title>Miroir dynamique inverse</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>...</dd>
-
- <dt>Solution :</dt>
-
- <dd>
-<example><pre>
-RewriteEngine on
-RewriteCond /miroir/du/site-distant/$1 -U
-RewriteRule ^http://www\.site-distant\.com/(.*)$ /miroir/du/site-distant/$1
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="retrieve-missing-data">
-
- <title>Récupérer des données manquantes depuis l'Intranet</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>C'est une méthode astucieuse permettant de faire
- fonctionner virtuellement un serveur web d'entreprise
- (<code>www.quux-corp.dom</code>) sur
- l'Internet (extérieur à l'entreprise), tout en maintenant et
- conservant dans la réalité ses données sur un serveur web
- (<code>www2.quux-corp.dom</code>) de l'Intranet (interne à
- l'entreprise) protégé par un pare-feu. L'astuce consiste, sur
- le serveur web externe, à récupérer à la volée sur le serveur interne
- les données demandées.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Tout d'abord, nous devons nous assurer que notre pare-feu
- protège bien le serveur web interne, et que seul le serveur
- web externe est autorisé à y récupérer des données. Dans le
- cas d'un filtrage par paquets, nous pourrions par exemple
- définir un jeu de règles du pare-feu du style :</p>
-
-<example><pre>
-<strong>ALLOW</strong> serveur www.quux-corp.dom Port >1024 -->
-serveur www2.quux-corp.dom Port <strong>80</strong>
-<strong>DENY</strong> serveur * Port * -->
-serveur www2.quux-corp.dom Port <strong>80</strong>
-</pre></example>
-
- <p>Il vous suffit d'adapter ces règles à la syntaxe de votre
- pare-feu. Nous pouvons maintenant définir les règles de
- <module>mod_rewrite</module> qui serviront à récupérer les
- données manquantes en arrière-plan via la fonctionnalité de
- mandataire :</p>
-
-<example><pre>
-RewriteRule ^/~([^/]+)/?(.*) /home/$1/.www/$2 [C]
-# L'utilisation de REQUEST_FILENAME ci dessous est correcte dans cet
-# exemple de contexte au niveau serveur car la règle qui fait référence
-# à REQUEST_FILENAME est chaînée à une règle qui définit
-# REQUEST_FILENAME.
-RewriteCond %{REQUEST_FILENAME} <strong>!-f</strong>
-RewriteCond %{REQUEST_FILENAME} <strong>!-d</strong>
-RewriteRule ^/home/([^/]+)/.www/?(.*) http://<strong>www2</strong>.quux-corp.dom/~$1/pub/$2 [<strong>P</strong>]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="load-balancing">
-
- <title>Répartition de charge</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Supposons que nous voulions répartir la charge du trafic
- vers <code>www.example.com</code> entre les serveurs
- <code>www[0-5].example.com</code> (un total de 6 serveurs).
- Comment y parvenir ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Il existe de nombreuses solutions à ce problème. Nous
- décrirons tout d'abord une variante assez connue basée sur
- DNS, puis une autre basée sur <module>mod_rewrite</module>
- :</p>
-
- <ol>
- <li>
- <strong>Round-Robin (tourniquet) DNS</strong>
-
- <p>La méthode de répartition de charge la plus simple
- consiste à utiliser le "DNS round-robin"
- (rotation d'adresses) de
- <code>BIND</code>. Vous devez seulement enregistrer les
- serveurs <code>www[0-9].example.com</code> de manière
- habituelle dans votre DNS à l'aide d'enregistrements de
- type A (adresse), comme suit :</p>
-
-<example><pre>
-www0 IN A 1.2.3.1
-www1 IN A 1.2.3.2
-www2 IN A 1.2.3.3
-www3 IN A 1.2.3.4
-www4 IN A 1.2.3.5
-www5 IN A 1.2.3.6
-</pre></example>
-
- <p>Puis vous ajoutez les entrées suivantes :</p>
-
-<example><pre>
-www IN A 1.2.3.1
-www IN A 1.2.3.2
-www IN A 1.2.3.3
-www IN A 1.2.3.4
-www IN A 1.2.3.5
-</pre></example>
-
- <p>Maintenant, lors de la résolution de
- <code>www.example.com</code>, <code>BIND</code> renvoie
- <code>www0-www5</code> - mais selon une permutation
- différente à chaque fois. De cette façon, les clients sont
- répartis entre les différents serveurs. Notez cependant
- que cette méthode de répartition de charge n'est pas
- parfaite, car les résolutions DNS sont mises en cache par
- les clients et les autres serveurs DNS du réseau, si
- bien que lorsqu'un client s'est vu résoudre
- <code>www.example.com</code> en un des
- <code>wwwN.example.com</code>, toutes ses requêtes ultérieures
- continueront d'aller vers la même adresse IP (et donc le
- même serveur), au lieu d'être réparties entre les autres
- serveurs. Le résultat est cependant globalement
- satisfaisant car les requêtes sont réparties
- collectivement entre chacun des serveurs web.</p>
- </li>
-
- <li>
- <strong>Répartition de charge basée sur DNS</strong>
-
- <p>Une méthode de répartition de charge sophistiquée basée
- sur DNS consiste à utiliser le programme
- <code>lbnamed</code> que l'on peut trouver à <a
- href="http://www.stanford.edu/~riepel/lbnamed/">
- http://www.stanford.edu/~riepel/lbnamed/</a>.
- Associé à des outils auxiliaires, il s'agit d'un programme
- en Perl 5 qui permet d'effectuer une véritable répartition
- de charge basée sur DNS.</p>
- </li>
-
- <li>
- <strong>Round-Robin basé sur la fonctionnalité de
- mandataire</strong>
-
- <p>Dans cette variante, nous utilisons
- <module>mod_rewrite</module> et sa fonctionnalité de
- mandataire. Tout d'abord, nous définissons
- <code>www0.example.com</code> comme un autre nom de
- <code>www.example.com</code> en ajoutant l'entrée</p>
-
-<example><pre>
-www IN CNAME www0.example.com.
-</pre></example>
-
- <p>dans le DNS. Puis nous définissons
- <code>www0.example.com</code> comme serveur mandataire
- seulement, c'est à dire que nous configurons cette machine
- de telle sorte que toutes les URLs qui lui arrivent soient
- simplement transmises, via le mandataire interne, vers un
- des 5 autres serveurs (<code>www1-www5</code>). Pour y
- parvenir, nous définissons tout d'abord un jeu de règles
- qui contacte un script de répartition de charge
- <code>lb.pl</code> pour toutes les URLs.</p>
-
-<example><pre>
-RewriteEngine on
-RewriteMap lb prg:/chemin/vers/lb.pl
-RewriteRule ^/(.+)$ ${lb:$1} [P,L]
-</pre></example>
-
- <p>Puis nous écrivons <code>lb.pl</code> :</p>
-
-<example><pre>
-#!/chemin/vers/perl
-##
-## lb.pl -- script de répartition de charge
-##
-
-$| = 1;
-
-$name = "www"; # la base du nom du serveur
-$first = 1; # le premier serveur (pas 0 ici, car 0 correspond à
- # moi-même)
-$last = 5; # le dernier serveur du tourniquet
-$domain = "foo.dom"; # le nom de domaine
-
-$cnt = 0;
-while (<STDIN>) {
- $cnt = (($cnt+1) % ($last+1-$first));
- $server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
- print "http://$server/$_";
-}
-
-##EOF##
-</pre></example>
-
- <note>Une dernière remarque : à quoi cela sert-il ?
- <code>www0.example.com</code>, quant à lui, n'est-il pas
- toujours surchargé ? La réponse est oui, il est surchargé,
- mais seulement avec des requêtes de mandataire ! Tous les
- traitements SSI, CGI, ePerl, etc... sont entièrement
- effectués sur les autres machines. Ceci peut fonctionner
- correctement pour un site complexe. Le plus grand risque
- réside ici dans le fait que www0 est un passage obligé et
- que s'il est hors service, les autres serveurs deviennent
- inaccessibles.</note>
- </li>
-
- <li>
- <strong>Répartiteur de charge dédié</strong>
-
- <p>Il existe aussi des solutions plus sophistiquées.
- Cisco, F5, et de nombreuses autres sociétés proposent
- des répartiteurs de charge matériels (utilisés en général
- en mode doublé à des fins de redondance), qui offrent une
- répartition de charge sophistiquée et des fonctionnalités
- de passage automatique en mode de fonctionnement par défaut
- en cas de problème. Cependant, des solutions logicielles
- offrent aussi des fonctionnalités similaires avec du
- matériel standard. Si vos besoins correspondent et si vous
- êtes assez riche, vous pouvez envisager ces solutions. La
- <a href="http://vegan.net/lb/">liste de diffusion lb-l</a>
- est un bon point de départ pour vos recherches.</p>
- </li>
- </ol>
- </dd>
- </dl>
-
- </section>
-
- <section id="new-mime-type">
-
- <title>Nouveau type MIME, nouveau service</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>On trouve de nombreux programmes CGI attractifs sur le
- réseau. Mais leur emploi est souvent rébarbatif, si bien que
- de nombreux webmasters ne les utilisent pas. Même la
- fonctionnalité de gestionnaire Action d'Apache pour les types
- MIME ne convient que lorsque les programmes CGI ne nécessitent
- pas d'URLs spéciales (réellement <code>PATH_INFO</code> et
- <code>QUERY_STRINGS</code>) en entrée. Tout d'abord,
- définissons un nouveau type de fichier ayant pour extension
- <code>.scgi</code> (pour CGI sécurisé) qui sera associé pour
- traitement au programme populaire <code>cgiwrap</code>. Le
- problème est le suivant : par exemple, si on utilise un style
- d'URL bien défini (voir ci-dessus), un fichier situé dans le
- répertoire home de l'utilisateur pourra correspondre à l'URL
- <code>/u/user/foo/bar.scgi</code>. Mais <code>cgiwrap</code>
- nécessite des URLs de la forme
- <code>/~user/foo/bar.scgi/</code>. La règle suivante apporte
- la solution :</p>
-
-<example><pre>
-RewriteRule ^/[uge]/<strong>([^/]+)</strong>/\.www/(.+)\.scgi(.*) ...
-... /interne/cgi/utilisateur/cgiwrap/~<strong>$1</strong>/$2.scgi$3 [NS,<strong>T=application/x-http-cgi</strong>]
-</pre></example>
-
- <p>Ou considérons ces autres programmes attractifs :
- <code>wwwlog</code> (qui affiche le journal des accès
- <code>access.log</code> pour un sous répertoire correspondant
- à une URL) et <code>wwwidx</code> (qui exécute Glimpse sur un
- sous répertoire correspondant à une URL). Nous devons fournir
- l'URL correspondante à ces programmes afin qu'ils sachent sur
- quel répertoire ils doivent agir. Mais c'est en général
- compliqué, car ils peuvent être appelés à nouveau
- par la forme d'URL alternative, c'est à dire que typiquement,
- nous exécuterions le programme <code>swwidx</code> depuis
- <code>/u/user/foo/</code> via un hyperlien vers</p>
-
-<example><pre>
-/internal/cgi/user/swwidx?i=/u/user/foo/
-</pre></example>
-
- <p>ce qui n'est pas satisfaisant, car nous devons expliciter
- <strong>à la fois</strong> la localisation du répertoire
- <strong>et</strong> la localisation du programme CGI dans
- l'hyperlien. Si nous devons nous réorganiser, il nous faudra
- beaucoup de temps pour modifier tous les hyperliens.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>La solution consiste ici à fournir un nouveau format d'URL
- qui redirige automatiquement vers la requête CGI appropriée.
- Pour cela, on définit les règles suivantes :</p>
-
-<example><pre>
-RewriteRule ^/([uge])/([^/]+)(/?.*)/\* /interne/cgi/utilisateur/wwwidx?i=/$1/$2$3/
-RewriteRule ^/([uge])/([^/]+)(/?.*):log /interne/cgi/utilisateur/wwwlog?f=/$1/$2$3
-</pre></example>
-
- <p>Et maintenant l'hyperlien qui renvoie vers
- <code>/u/user/foo/</code> se réduit à</p>
-
-<example><pre>
-HREF="*"
-</pre></example>
-
- <p>qui est automatiquement transformé en interne en</p>
-
-<example><pre>
-/internal/cgi/user/wwwidx?i=/u/user/foo/
-</pre></example>
-
- <p>Une approche similaire permet d'invoquer le programme CGI
- du journal des accès lorsque l'hyperlien <code>:log</code> est
- utilisé.</p>
- </dd>
- </dl>
-
- </section>
-
- <section id="on-the-fly-content">
-
- <title>Régéneration de contenu à la volée</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Voici une fonctionnalité vraiment ésotérique : des pages
- générées dynamiquement mais servies statiquement, c'est à
- dire que les pages doivent être servies comme des pages
- purement statiques (lues depuis le système de fichiers et
- servies en l'état), mais doivent être générées dynamiquement
- par le serveur web si elles sont absentes. Ainsi, vous pouvez
- avoir des pages générées par CGI qui sont servies statiquement
- à moins qu'un administrateur (ou une tâche de
- <code>cron</code>) ne supprime les
- contenus statiques. Les contenus sont ensuite actualisés.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- A cet effet, on utilise le jeu de règles suivant :
-
-<example><pre>
-# Cet exemple n'est valable que dans un contexte de répertoire
-RewriteCond %{REQUEST_FILENAME} <strong>!-s</strong>
-RewriteRule ^page\.<strong>html</strong>$ page.<strong>cgi</strong> [T=application/x-httpd-cgi,L]
-</pre></example>
-
- <p>Ainsi, une requête pour <code>page.html</code> entraîne
- l'exécution interne de la page <code>page.cgi</code>
- correspondante si <code>page.html</code> n'existe pas
- ou possède une taille de fichier nulle. L'astuce réside ici
- dans le fait que <code>page.cgi</code> est un script CGI
- qui (en plus de <code>STDOUT</code>) écrit sa sortie dans le
- fichier <code>page.html</code>. Une fois le script exécuté, le
- serveur sert la page <code>page.html</code> fraîchement
- générée. Si le webmaster
- veut actualiser les contenus, il lui suffit de supprimer le
- fichier <code>page.html</code> (le plus souvent via une tâche
- de <code>cron</code>).</p>
- </dd>
- </dl>
-
- </section>
-
- <section id="autorefresh">
-
- <title>Actualisation automatique d'un document</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Lorsque nous créons une page web complexe, ne serait-il pas
- souhaitable que le navigateur web actualise automatiquement la
- page chaque fois que nous en sauvegardons une nouvelle version
- à partir de notre éditeur ? Impossible ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Non ! Nous allons pour cela combiner la fonctionnalité MIME
- multipart, la fonctionnalité NPH du serveur web et la
- puissance de <module>mod_rewrite</module> pour la manipulation
- d'URLs. Tout d'abord, nous définissons une nouvelle
- fonctionnalité pour les URLs : l'ajout de
- <code>:refresh</code> à toute URL fait que la 'page' est
- actualisée chaque fois que la ressource est mise à jour dans
- le système de fichiers.</p>
-
-<example><pre>
-RewriteRule ^(/[uge]/[^/]+/?.*):refresh /interne/cgi/apache/nph-refresh?f=$1
-</pre></example>
-
- <p>Nous appelons maintenant cette URL</p>
-
-<example><pre>
-/u/foo/bar/page.html:refresh
-</pre></example>
-
- <p>ce qui entraîne en interne l'invocation de l'URL</p>
-
-<example><pre>
-/interne/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
-</pre></example>
-
- <p>Il ne reste plus qu'à écrire le script CGI. Bien que l'on
- écrive habituellement dans ces cas "laissé à la charge du
- lecteur à titre d'exercice", ;-) je vous l'offre, aussi.</p>
-
-<example><pre>
-#!/sw/bin/perl
-##
-## nph-refresh -- script NPH/CGI pour l'actualisation automatique de
-## pages
-## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
-##
-$| = 1;
-
-# éclate la variable QUERY_STRING
-@pairs = split(/&/, $ENV{'QUERY_STRING'});
-foreach $pair (@pairs) {
- ($name, $value) = split(/=/, $pair);
- $name =~ tr/A-Z/a-z/;
- $name = 'QS_' . $name;
- $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
- eval "\$$name = \"$value\"";
-}
-$QS_s = 1 if ($QS_s eq '');
-$QS_n = 3600 if ($QS_n eq '');
-if ($QS_f eq '') {
- print "HTTP/1.0 200 OK\n";
- print "Content-type: text/html\n\n";
- print "&lt;b&gt;ERREUR&lt;/b&gt;: Aucun fichier fourni\n";
- exit(0);
-}
-if (! -f $QS_f) {
- print "HTTP/1.0 200 OK\n";
- print "Content-type: text/html\n\n";
- print "&lt;b&gt;ERREUR&lt;/b&gt;: Fichier $QS_f non trouvé\n";
- exit(0);
-}
-
-sub print_http_headers_multipart_begin {
- print "HTTP/1.0 200 OK\n";
- $bound = "ThisRandomString12345";
- print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
- &print_http_headers_multipart_next;
-}
-
-sub print_http_headers_multipart_next {
- print "\n--$bound\n";
-}
-
-sub print_http_headers_multipart_end {
- print "\n--$bound--\n";
-}
-
-sub displayhtml {
- local($buffer) = @_;
- $len = length($buffer);
- print "Content-type: text/html\n";
- print "Content-length: $len\n\n";
- print $buffer;
-}
-
-sub readfile {
- local($file) = @_;
- local(*FP, $size, $buffer, $bytes);
- ($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
- $size = sprintf("%d", $size);
- open(FP, "&lt;$file");
- $bytes = sysread(FP, $buffer, $size);
- close(FP);
- return $buffer;
-}
-
-$buffer = &readfile($QS_f);
-&print_http_headers_multipart_begin;
-&displayhtml($buffer);
-
-sub mystat {
- local($file) = $_[0];
- local($time);
-
- ($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
- return $mtime;
-}
-
-$mtimeL = &mystat($QS_f);
-$mtime = $mtime;
-for ($n = 0; $n &lt; $QS_n; $n++) {
- while (1) {
- $mtime = &mystat($QS_f);
- if ($mtime ne $mtimeL) {
- $mtimeL = $mtime;
- sleep(2);
- $buffer = &readfile($QS_f);
- &print_http_headers_multipart_next;
- &displayhtml($buffer);
- sleep(5);
- $mtimeL = &mystat($QS_f);
- last;
- }
- sleep($QS_s);
- }
-}
-
-&print_http_headers_multipart_end;
-
-exit(0);
-
-##EOF##
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="mass-virtual-hosting">
-
- <title>Hébergement virtuel de masse</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>La fonctionnalité <directive type="section" module="core"
- >VirtualHost</directive> d'Apache est intéressante et
- fonctionne de manière satisfaisante jusqu'à quelques
- douzaines de serveurs virtuels. Par contre, si vous êtes un
- FAI et devez héberger des centaines de serveurs virtuels,
- cette méthode n'est pas optimale.</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Pour fournir cette fonctionnalité avec
- <module>mod_rewrite</module>, on fait correspondre à notre espace de
- nommage la page web ou même le répertoire complet distants en
- utilisant la fonctionnalité <dfn>Mandataire</dfn>
- (drapeau <code>[P]</code>) :</p>
-
-<example><pre>
-##
-## vhost.map
-##
-www.vhost1.dom:80 /chemin/vers/racine-doc/vhost1
-www.vhost2.dom:80 /chemin/vers/racine-doc/vhost2
- :
-www.vhostN.dom:80 /chemin/vers/racine-doc/vhostN
-</pre></example>
-
-<example><pre>
-##
-## httpd.conf
-##
- :
-# utilisation du nom d'hôte canonique pour les redirections, etc...
-UseCanonicalName on
-
- :
-# ajout du serveur virtuel en tête du format CLF
-CustomLog /chemin/vers/access_log "%{VHOST}e %h %l %u %t \"%r\" %>s %b"
- :
-
-# activation du moteur de réécriture pour le serveur principal
-RewriteEngine on
-
-# définition de deux tables de correspondances : une première pour
-# corriger les URLs et une seconde qui associe les serveurs virtuels
-# disponibles avec leurs racines des documents correspondantes.
-RewriteMap lowercase int:tolower
-RewriteMap vhost txt:/chemin/vers/vhost.map
-
-# et enfin sélection proprement dite du serveur virtuel approprié via
-# une seule règle longue et complexe :
-#
-# 1. on s'assure de ne pas sélectionner un hôte virtuel pour les
-# adresses communes
-
-RewriteCond %{REQUEST_URI} !^/adresse-commune1/.*
-RewriteCond %{REQUEST_URI} !^/adresse-commune2/.*
- :
-RewriteCond %{REQUEST_URI} !^/adresse-communeN/.*
-#
-# 2. on vérifie que l'on dispose bien d'un en-tête Host, car
-# actuellement, cette méthode ne peut faire de l'hébergement virtuel
-# qu'avec cet en-tête
-RewriteCond %{HTTP_HOST} !^$
-#
-# 3. mise en minuscules du nom d'hôte
-RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$
-#
-# 4. recherche ce ce nom d'hôte dans vhost.map et
-# enregistrement de celui-ci seulement s'il s'agit d'un chemin
-# (et non "NONE" en provenance de la condition précédente)
-RewriteCond ${vhost:%1} ^(/.*)$
-#
-# 5. nous pouvons enfin faire correspondre l'URL avec la racine des
-# documents correspondant au serveur virtuel approprié et enregistrer
-# ce dernier à des fins de journalisation
-RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}]
- :
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="host-deny">
-
- <title>Interdiction d'hôtes</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment interdire l'accès à notre serveur à une liste
- d'hôtes ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Pour Apache >= 1.3b6 :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteMap hôtes-interdits txt:/chemin/vers/hôtes-interdits
-RewriteCond ${hôtes-interdits:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
-RewriteCond ${hôtes-interdits:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
-RewriteRule ^/.* - [F]
-</pre></example>
-
- <p>Pour Apache <= 1.3b6 :</p>
-
-<example><pre>
-RewriteEngine on
-RewriteMap hôtes-interdits txt:/chemin/vers/hôtes-interdits
-RewriteRule ^/(.*)$ ${hôtes-interdits:%{REMOTE_HOST}|NOT-FOUND}/$1
-RewriteRule !^NOT-FOUND/.* - [F]
-RewriteRule ^NOT-FOUND/(.*)$ ${hôtes-interdits:%{REMOTE_ADDR}|NOT-FOUND}/$1
-RewriteRule !^NOT-FOUND/.* - [F]
-RewriteRule ^NOT-FOUND/(.*)$ /$1
-</pre></example>
-
-<example><pre>
-##
-## hosts.deny
-##
-## ATTENTION! Ceci est une table de correspondances, pas une liste,
-## même si on l'utilise en tant que telle. mod_rewrite l'interprète
-## comme un ensemble de paires clé/valeur ; chaque entrée doit donc
-## au moins posséder une valeur fictive "-".
-##
-
-193.102.180.41 -
-bsdti1.sdm.de -
-192.76.162.40 -
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="proxy-deny">
-
- <title>Interdiction du mandataire</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment interdire l'utilisation du mandataire d'Apache pour
- un certain hôte, ou même seulement pour un utilisateur
- de cet hôte ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>Nous devons tout d'abord nous assurer que
- <module>mod_rewrite</module> arrive après(!)
- <module>mod_proxy</module> dans le fichier de configuration
- lors de la compilation du serveur web Apache. De cette façon,
- il est appelé <em>avant</em> <module>mod_proxy</module>. Nous
- pouvons ensuite définir cette règle pour une interdiction
- dépendant de l'hôte :</p>
-
-<example><pre>
-RewriteCond %{REMOTE_HOST} <strong>^hôte-à-rejeter\.mon-domaine\.com$</strong>
-RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
-</pre></example>
-
- <p>...et celle-ci pour une interdiction dépendant de
- utilisateur@hôte :</p>
-
-<example><pre>
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>^utilisateur-à-
-rejeter@hôte-à-rejeter\.mon-domaine\.com$</strong>
-RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="special-authentication">
-
- <title>Variante particulière d'authentification</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>On a parfois besoin d'une authentification très
- particulière, par exemple une authentification qui vérifie la
- présence d'un utilisateur dans une liste explicitement
- définie. Seuls ceux qui sont présents dans la liste se voient
- accorder un accès, et ceci sans avoir à
- s'identifier/authentifier (comme c'est le cas avec une
- authentification de base via <module>mod_auth</module>).</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On définit une liste de conditions de réécriture pour
- interdire l'accès à tout le monde, sauf aux utilisateurs
- autorisés :</p>
-
-<example><pre>
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami1@client1.quux-corp\.com$</strong>
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami2</strong>@client2.quux-corp\.com$
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami3</strong>@client3.quux-corp\.com$
-RewriteRule ^/~quux/seulement-pour-les-amis/ - [F]
-</pre></example>
- </dd>
- </dl>
-
- </section>
-
- <section id="referer-deflector">
-
- <title>Redirection basée sur le référent</title>
-
- <dl>
- <dt>Description :</dt>
-
- <dd>
- <p>Comment écrire un programme souple qui redirige certaines
- URLs en se basant sur l'en-tête HTTP "Referer", et peut être
- configuré avec autant de pages de référence
- que l'on veut ?</p>
- </dd>
-
- <dt>Solution :</dt>
-
- <dd>
- <p>On utilise le jeu de règles vraiment astucieux suivant :</p>
-
-<example><pre>
-RewriteMap deflector txt:/chemin/vers/deflector.map
-
-RewriteCond %{HTTP_REFERER} !=""
-RewriteCond ${deflector:%{HTTP_REFERER}} ^-$
-RewriteRule ^.* %{HTTP_REFERER} [R,L]
-
-RewriteCond %{HTTP_REFERER} !=""
-RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
-RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L]
-</pre></example>
-
- <p>... en association avec la table de réécriture
- correspondante :</p>
-
-<example><pre>
-##
-## deflector.map
-##
-
-http://www.mauvais-sujets.com/mauvais/index.html -
-http://www.mauvais-sujets.com/mauvais/index2.html -
-http://www.mauvais-sujets.com/mauvais/index3.html http://quelque-part.com/
-</pre></example>
-
- <p>Les requêtes sont redirigées vers la page de référence
- (lorsque la valeur correspondant à la clé extraite de la table
- de correspondances est égale à "<code>-</code>"), ou vers une
- URL spécifique (lorsqu'une URL est définie dans la table de
- correspondances comme second argument).</p>
- </dd>
- </dl>
-
- </section>
-
-</manualpage>
-
projects / apache / commitdiff