From: AndrĂ© Malo Date: Fri, 10 Dec 2010 23:44:48 +0000 (+0000) Subject: remove those files and enter the html transformations as orphans until it's X-Git-Tag: 2.3.10~25 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=f3ac1d322f1ad754228190849fd30e164d276cdb;p=apache remove those files and enter the html transformations as orphans until it's cleaned up by the french translators git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1044539 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/rewrite/rewrite_guide.xml.fr b/docs/manual/rewrite/rewrite_guide.xml.fr deleted file mode 100644 index b874d9d37d..0000000000 --- a/docs/manual/rewrite/rewrite_guide.xml.fr +++ /dev/null @@ -1,863 +0,0 @@ - - - - - - - - - - - Rewrite - - Guide de réécriture des URLs - - - -

Ce document complète la documentation de référence du - module mod_rewrite. Il décrit de quelle manière on - peut utiliser le module Apache mod_rewrite 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.

- - 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 - [PT] si vous utilisez les modules - mod_alias, mod_userdir, etc... Un - jeu de règles défini dans le contexte du serveur devra aussi être - adapté pour être utilisé dans un contexte .htaccess. - 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. - - -Documentation du module -Introduction à mod_rewrite -Guide de réécriture -avancé - exemples utiles avancés -Détails techniques - - -
- -URLs canoniques - -
-
Description :
- -
-

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.

-
- -
Solution :
- -
-

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, /~user est remplacé par - l'expression canonique /u/user, et une éventuelle - absence du slash à la fin de /u/user est corrigée.

- -
-RewriteRule   ^/~([^/]+)/?(.*)    /u/$1/$2  [R]
-RewriteRule   ^/u/([^/]+)$  /$1/$2/   [R]
-
 -
-
- -
- -
Noms d'hôtes canoniques - -
-
Description :
- -
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 www.example.com à la place de - example.com, vous devez utiliser une solution - de ce style.
- -
Solution :
- -
-

Pour les sites écoutant sur un port autre que 80:

-
-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]
-
 - -

Et pour un site écoutant sur le port 80

-
-RewriteCond %{HTTP_HOST}   !^www\.exemple\.com [NC]
-RewriteCond %{HTTP_HOST}   !^$
-RewriteRule ^/?(.*)         http://www.example.com/$1 [L,R,NE]
-
 -

- Si vous souhaitez que cette règle s'applique à tous les noms de - domaine - en d'autres termes, si vous voulez rediriger - example.com vers - www.example.com pour toutes les valeurs - possibles de example.com, vous pouvez utiliser - le jeu de règles suivants :

- -
-RewriteCond %{HTTP_HOST} !^www\. [NC]
-RewriteCond %{HTTP_HOST} !^$
-RewriteRule ^/?(.*) http://www.%{HTTP_HOST}/$1 [L,R,NE]
-
 -

- Vous pouvez utiliser ce jeu de règles aussi bien dans le fichier - de configuration de votre serveur principal que dans un fichier - .htaccess placé dans le répertoire défini par la - directive DocumentRoot du serveur.

-
-
- -
- -
- - <code>DocumentRoot</code>déplacé - -
-
Description :
- -
-

En général, la directive DocumentRoot correspond directement à l'URL -"/" 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 -/a-propos-de/. Pour ce faire, on peut utiliser le jeu de -règles suivant :

-
- -
Solution :
- -
-

On redirige l'URL / vers - /a-propos-de/: -

- -
-RewriteEngine on
-RewriteRule   ^/$  /a-propos-de/  [R]
-
 - -

Notez que le même effet peut être obtenu à l'aide de la directive - RedirectMatch :

- - -RedirectMatch ^/$ http://example.com/apropos/ - -

Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres -termes, il réécrit une requête pour http://example.com/, -mais ne réécrira pas une requête pour -http://example.com/page.html. 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 DocumentRoot que de -procéder à une réécriture d'URLs.

-
-
- -
- -
- - Problème du slash de fin - -
-
Description :
- -

La plupart des problèmes de "slash de fin" peuvent être - résolus grâce aux techniques décrites dans ce sujet - de la FAQ. 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.

-
- -
Solution :
- -
-

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 - image.gif dans /~quux/foo/index.html - deviendrait /~quux/image.gif sans la redirection - externe !

- -

Pour y parvenir, on peut utiliser des règles de ce style :

- -
-RewriteEngine  on
-RewriteBase    /~quux/
-RewriteRule    ^foo$  foo/  [R]
-
 - -

Vous pouvez aussi ajouter ce qui suit dans un fichier - .htaccess situé dans le répertoire contenant la - ressource. Notez cependant que cela augmente la charge du processeur.

- -
-RewriteEngine  on
-RewriteBase    /~quux/
-RewriteCond    %{REQUEST_FILENAME}  -d
-RewriteRule    ^(.+[^/])$           $1/  [R]
-
 -
-
- -
- -
- - Déplacement des répertoires home vers un autre serveur - -
-
Description :
- -
-

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.

-
- -
Solution :
- -
-

Avec mod_rewrite, la solution est - évidente. Sur l'ancien serveur web, on redirige simplement - toutes les URLs du style /~user/chemin vers - http://nouveau-serveur/~user/chemin.

- -
-RewriteEngine on
-RewriteRule   ^/~(.+)  http://nouveau-serveur/~$1  [R,L]
-
 -
-
- -
- -
- - Recherche de pages dans plus d'un répertoire - -
-
Description :
- -
-

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.

-
- -
Solution :
- -
-

On définit explicitement un jeu de règles qui recherche les - fichiers dans les répertoires.

- -
-RewriteEngine on
-
-#   on cherche tout d'abord dans dir1/...
-#   ... et si on trouve, on est content et on arrête :
-RewriteCond         %{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}  -f
-RewriteRule  ^(.+)  %{DOCUMENT_ROOT}/dir1/$1  [L]
-
-#   on cherche ensuite dans dir2/...
-#   ... et si on trouve, on est content et on arrête :
-RewriteCond         %{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}  -f
-RewriteRule  ^(.+)  %{DOCUMENT_ROOT}/dir2/$1  [L]
-
-#   sinon, on continue la recherche avec d'autres directives Alias
-#   ou ScriptAlias, etc...
-RewriteRule   ^(.+)  -  [PT]
-
 -
-
- -
- -
- - Définir des variables d'environnement en fonction de - certaines parties de l'URL - -
-
Description :
- -
-

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.

-
- -
Solution :
- -
-

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 - /foo/S=java/bar/ sera traduite en - /foo/bar/ et la variable d'environnement - STATUS aura pour valeur "java".

- -
-RewriteEngine on
-RewriteRule   ^(.*)/S=([^/]+)/(.*)    $1/$3 [E=STATUS:$2]
-
 -
-
- -
- -
- - Hôtes virtuels basés sur l'utilisateur - -
-
Description :
- -
-

Supposons que vous vouliez atteindre la page d'accueil des - utilisateurs sur une même machine au moyen de l'URL - www.nom-utilisateur.hôte.domaine.com, - 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.

-
- -
Solution :
- -
-

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 - http://www.nom-utilisateur.hôte.com/chemin vers - /home/nom-utilisateur/chemin :

- -
-RewriteEngine on
-RewriteCond   %{HTTP_HOST}                 ^www\.([^.]+)\.host\.com$
-RewriteRule   ^(.*) /home/%1$1
-
 -

Les parenthèses utilisées dans une directive RewriteCond sont capturées dans les -références arrières %1, %2, etc..., alors que -les parenthèses utilisées dans une directive RewriteRule sont capturées dans les -références arrières $1, $2, etc...

-
-
- -
- -
- - Redirection des répertoires d'accueil pour les étrangers - -
-
Description :
- -
-

On veut rediriger les URLs des répertoires d'accueil vers - un autre serveur www.quelque-part.com lorsque - l'utilisateur demandeur n'appartient pas au domaine local - notre-domaine.com. On rencontre parfois cette - situation dans un contexte d'hôtes virtuels.

-
- -
Solution :
- -
-

Juste une condition de réécriture :

- -
-RewriteEngine on
-RewriteCond   %{REMOTE_HOST}  !^.+\.notre-domaine\.com$
-RewriteRule   ^(/~.+)         http://www.quelque-part.com/$1 [R,L]
-
 -
-
- -
- -
- - Redirection des ancrages - -
-
Description :
- -
-

Par défaut, la redirection vers un ancrage HTML ne fonctionne - pas, car mod_rewrite échappe le caractère # en le - transformant en %23, ce qui rend la redirection - inopérante.

-
- -
Solution :
- -
-

On utilise le drapeau [NE] dans la règle - RewriteRule. NE signifie "No Escape". -

-
-
- -
- -
- - Réécriture dépendant de l'heure - -
-
Description :
- -
-

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 mod_rewrite ?

-
- -
Solution :
- -
-

Il existe de nombreuses variables nommées - TIME_xxx utilisables dans les conditions de - réécriture. Utilisées en conjonction avec les modèles de - comparaison lexicographique spéciaux <STRING, - >STRING et =STRING, elles - permettent d'effectuer des redirections dépendant de - l'heure :

- -
-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
-
 - -

Avec cet exemple, l'URL foo.html renvoie - le contenu de foo.jour.html durant le - créneau horaire 07:00-19:00, et le contenu de - foo.nuit.html le reste du temps. Agréable - fonctionnalité pour une page d'accueil...

-
-
- -
- -
- - Compatibilité ascendante pour une migration de YYYY vers - XXXX - -
-
Description :
- -
-

Comment conférer une compatibilité ascendante aux URLs - (existant encore virtuellement) après avoir migré - document.YYYY vers document.XXXX, - c'est à dire après avoir par exemple traduit un lot de - fichiers .html en fichiers .phtml - ?

-
- -
Solution :
- -
-

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.

- - -
-#   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
-
 -
-
- -
- -
- - De l'ancien au nouveau (en interne) - -
-
Description :
- -
-

Supposons que nous ayons récemment renommé la page - foo.html en bar.html, 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.

-
- -
Solution :
- -
-

On réécrit l'ancienne URL en interne vers la nouvelle via - la règle suivante :

- -
-RewriteEngine  on
-RewriteBase    /~quux/
-RewriteRule    ^foo\.html$  bar.html
-
 -
-
- -
- -
- - De l'ancien au nouveau (en externe) - -
-
Description :
- -
-

Supposons toujours que nous ayons récemment renommé la page - foo.html en bar.html, 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.

-
- -
Solution :
- -
-

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 :

- -
-RewriteEngine  on
-RewriteBase    /~quux/
-RewriteRule    ^foo\.html$  bar.html  [R]
-
 -
-
- -
- -
- - De statique à dynamique - -
-
Description :
- -
-

Comment transformer une page statique foo.html - en sa variante dynamique foo.cgi de manière - transparente, c'est à dire sans en avertir le - navigateur/utilisateur.

-
- -
Solution :
- -
-

On réécrit simplement l'URL en script CGI et force le - gestionnaire de contenu à cgi-script de façon - à ce que le script s'exécute en tant que programme CGI. - Ainsi, une requête vers /~quux/foo.html conduit - en interne à l'invocation de - /~quux/foo.cgi.

- -
-RewriteEngine  on
-RewriteBase    /~quux/
-RewriteRule    ^foo\.html$  foo.cgi  [H=cgi-script]
-
 -
-
- -
- -
- - Blocage des robots - -
-
Description :
- -
-

Comment empêcher un robot vraiment gênant de collecter les - pages d'une partie spécifique du site web ? Un fichier - /robots.txt comportant les entrées du "Protocole - d'Exclusion des Robots" ne suffit généralement pas à en venir - à bout.

-
- -
Solution :
- -
-

On utilise un jeu de règles qui interdit les URLs de la - partie du site web concernée /~quux/foo/arc/ - (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.

- -
-RewriteCond %{HTTP_USER_AGENT}   ^NameOfBadRobot.*
-RewriteCond %{REMOTE_ADDR}       ^123\.45\.67\.[8-9]$
-RewriteRule ^/~quux/foo/arc/.+   -   [F]
-
 -
-
- -
- -
- - Blocage du référencement à chaud (Hotlinking) d'images - -
-
Description :
- -
-

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.

-
- -
Solution :
- -
-

Cette technique repose sur la valeur de la variable - optionnelle HTTP_REFERER. 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.

-

Il y a plusieurs manières de gérer cette situation.

- -

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 www.example.com.

- -
-RewriteCond %{HTTP_REFERER} !^$
-RewriteCond %{HTTP_REFERER} !www.example.com [NC]
-RewriteRule \.(gif|jpg|png)$    -   [F,NC]
-
 - -

Dans le second exemple, plutôt que de rejeter la requête, - nous affichons une autre image à la place.

- -
-RewriteCond %{HTTP_REFERER} !^$
-RewriteCond %{HTTP_REFERER} !www.example.com [NC]
-RewriteRule \.(gif|jpg|png)$    /images/go-away.png   [R,NC]
-
 - -

Dans le troisième exemple, nous redirigeons la requête vers - une image appartenant à un site tiers.

- - -
-RewriteCond %{HTTP_REFERER} !^$
-RewriteCond %{HTTP_REFERER} !www.example.com [NC]
-RewriteRule \.(gif|jpg|png)$ http://other.site.com/image.gif   [R,NC]
-
 -

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.

- -
-
- -
- -
- - Interdiction du mandataire - -
-
Description :
- -
-

Comment interdire l'utilisation du mandataire d'Apache à un - certain hôte, ou même à un utilisateur d'un certain hôte ?

-
- -
Solution :
- -
-

Nous devons tout d'abord nous assurer que - mod_rewrite se situe en dessous (!) de - mod_proxy dans le fichier de configuration - lors de la compilation du serveur web Apache. De cette façon, - il est appelé avant mod_proxy. Nous - pouvons alors utiliser la règle suivante pour une interdiction - concernant un hôte...

- -
-RewriteCond %{REMOTE_HOST} ^mauvais-hôte\.mon-domaine\.com$
-RewriteRule !^http://[^/.]\.mon-domaine.com.*  - [F]
-
 - -

...et celle-ci pour une interdiction concernant un - utilisateur d'un certain hôte :

- -
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}
-^mauvais-sujet@mauvais-hôte\.mon-domaine\.com$
-RewriteRule !^http://[^/.]\.mon-domaine.com.*  - [F]
-
 -
-
- -
- -
- - Moteur de réécriture externe - -
-
Description :
- -
-

Une question de la Faq : comment résoudre le problème - FOO/BAR/QUUX/etc. ? mod_rewrite ne semble pas - devoir y apporter de solution...

-
- -
Solution :
- -
-

Utiliser une RewriteMap ou table de réécriture externe, c'est - à dire un programme qui agit de la même façon qu'une - RewriteMap. Il - doit être lancé une fois au démarrage d'Apache, recevoir les - URLs des requêtes sur STDIN, et restituer l'URL - résultante (en général réécrite) sur STDOUT (dans - cet ordre !).

- -
-RewriteEngine on
-RewriteMap    quux-table       prg:/chemin/vers/table.quux.pl
-RewriteRule   ^/~quux/(.*)$  /~quux/${quux-table:$1}
-
 - -
-#!/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 $_;
-}
-
 - -

Ceci n'est qu'un exemple de démonstration qui ne fait que - réécrire les URLs du style /~quux/foo/... vers - /~quux/bar/.... En fait, vous pouvez programmer - la substitution que vous voulez. Notez cependant que si de - tels programmes peuvent aussi être utilisés - par un utilisateur standard, seul l'administrateur du système - peut les écrire.

-
-
- -
- - - diff --git a/docs/manual/rewrite/rewrite_guide_advanced.xml.fr b/docs/manual/rewrite/rewrite_guide_advanced.xml.fr deleted file mode 100644 index e7d0e5f168..0000000000 --- a/docs/manual/rewrite/rewrite_guide_advanced.xml.fr +++ /dev/null @@ -1,1374 +0,0 @@ - - - - - - - - - - - Rewrite - - Guide de réécriture des URLs - Sujets avancés - - - -

Ce document complémente la - documentation de référence du - module mod_rewrite. Il décrit les différentes - manières d'utiliser le module d'Apache mod_rewrite - 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.

- - 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 - [PT] si les modules mod_alias et - mod_userdir 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 - .htaccess). 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. - - -Documentation du -module -Introduction à -mod_rewrite -Guide de réécriture - exemples -utiles -Détails techniques - - -
- - Accès à une grappe de serveurs via un espace d'adressage - compatible - -
-
Description :
- -
-

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 indépendantes 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.

-
- -
Solution :
- -
-

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 :

- -
-utilisateur1  serveur_utilisateur1
-utilisateur2  serveur_utilisateur2
-:      :
-
 - -

On les enregistre sous forme de fichiers - map.xxx-vers-serveur. On doit ensuite faire - rediriger à tous les serveurs les URLs de la forme :

- -
-/u/utilisateur/chemin
-/g/groupe/chemin
-/e/entité/chemin
-
 - -

vers

- -
-http://serveur-physique/u/utilisateur/chemin
-http://serveur-physique/g/groupe/chemin
-http://serveur-physique/e/entité/chemin
-
 - -

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) :

- -
-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/([^/]+)/?(.*)
-http://${utilisateur-vers-serveur:$1|serveur0}/u/$1/$2
-RewriteRule   ^/g/([^/]+)/?(.*)
-http://${groupe-vers-serveur:$1|serveur0}/g/$1/$2
-RewriteRule   ^/e/([^/]+)/?(.*)
-http://${entité-vers-serveur:$1|serveur0}/e/$1/$2
-
-RewriteRule   ^/([uge])/([^/]+)/?$          /$1/$2/.www/
-RewriteRule   ^/([uge])/([^/]+)/([^.]+.+)   /$1/$2/.www/$3\
-
 -
-
- -
- -
- - Répertoires utilisateurs structurés - -
-
Description :
- -
-

Certains sites possédant des milliers d'utilisateurs - organisent les répertoires home de manière - structurée, c'est à dire 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, /~foo/chemin est dans - /home/f/foo/.www/chemin, tandis - que /~bar/chemin est dans - /home/b/bar/.www/chemin.

-
- -
Solution :
- -
-

Le jeu de règles suivant permet de développer les URLs avec - tilde selon la représentation ci-dessus.

- -
-RewriteEngine on
-RewriteRule   ^/~(([a-z])[a-z0-9]+)(.*)  /home/$2/$1/.www$3
-
 -
-
- -
- -
- - Réorganisation du système de fichiers - -
-
Description :
- -
-

Voici un cas d'espèce : une application très efficace qui - fait un usage intensif de règles RewriteRule - 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 : net.sw - 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 :

- -
-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/
-
 - -

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.

-
- -
Solution :
- -
-

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 - /e/netsw/.www/ comme suit :

- -
--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
-
 - -

Le sous-répertoire DATA/ contient la structure - de répertoires proprement dite mentionnée plus haut, c'est - à dire les véritables ressources - net.sw et est mis à jour - automatiquement via rdist à 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 - DATA/ à 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 DocumentRoot du serveur afin de - réécrire le chemin d'URL public /net.sw/ vers le - chemin interne /e/netsw :

- -
-RewriteRule  ^net.sw$       net.sw/        [R]
-RewriteRule  ^net.sw/(.*)$  e/netsw/$1
-
 - -

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 - /e/netsw/.www/.wwwacl :

- -
-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
-
 - -

Quelques indices pour l'interprétation :

- -
    -
  1. Remarquez le drapeau L (last) et l'absence - de chaîne de substitution ('-') dans la - quatrième partie.
    2. - -
  2. Remarquez le caractère ! (not) et le - drapeau C (chain) dans la première règle de la - dernière partie.
    3. - -
  3. Remarquez le modèle qui correspond à tout dans la - dernière règle.
    4. -
-
-
- -
- -
- - Rediriger les URLs erronées vers un autre serveur Web - -
-
Description :
- -
-

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 ErrorDocument en Perl, mais il - existe aussi une solution avec mod_rewrite. - Notez cependant que les performances sont moindres qu'avec - l'utilisation d'un script CGI ErrorDocument !

-
- -
Solution :
- -
-

La première solution possède des performances supérieures - mais moins de souplesse, et est moins sure :

- -
-RewriteEngine on
-RewriteCond  %{DOCUMENT_ROOT/%{REQUEST_URI}  !-f
-RewriteRule   ^(.+)                             http://serveurB.dom/$1
-
 - -

Le problème réside dans le fait que seules les pages - situées dans la racine DocumentRoot 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 :

- -
-RewriteEngine on
-RewriteCond   %{REQUEST_URI} !-U
-RewriteRule   ^(.+)          http://serveurB.dom/$1
-
 -reprendre ici -

On utilise ici la fonctionnalité de prévision des URLs - futures de mod_rewrite. 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 ErrorDocument.

-
-
- -
- -
- - Multiplexeur d'accès aux archives - -
-
Description :
- -
-

Connaissez-vous la grande archive CPAN (Comprehensive Perl Archive - Network) située à http://www.perl.com/CPAN ? - 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 - mod_rewrite ?

-
- -
Solution :
- -
-

Premièrement, remarquons que depuis la version 3.0.0, - mod_rewrite accepte aussi le préfixe - "ftp:" dans les redirections. Et deuxièmement, - l'approximation de la localisation peut être effectuée par une - table de correspondances RewriteMap, 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.

- -
-RewriteEngine on
-RewriteMap    multiplex                txt:/chemin/vers/map.cxan
-RewriteRule   ^/CxAN/(.*)              %{REMOTE_HOST}::$1                 [C]
-RewriteRule   ^.+\.([a-zA-Z]+)::(.*)$
-${multiplex:$1|ftp.défaut.dom}$2  [R,L]
-
 - -
-##
-##  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##
-
 -
-
- -
- -
- - Contenu dépendant du navigateur - -
-
Description :
- -
-

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.

-
- -
Solution :
- -
-

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 - foo.html est réécrite en foo.NS.html - et la réécriture s'arrête. Si le navigateur est "Lynx" ou - "Mozilla" version 1 ou 2, la page - foo.html est réécrite en - foo.20.html. Tous les autres navigateurs - reçoivent la page foo.32.html. Voici le jeu de - règles :

- -
-RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/3.*
-RewriteRule ^foo\.html$         foo.NS.html          [L]
-
-RewriteCond %{HTTP_USER_AGENT}  ^Lynx/.*         [OR]
-RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/[12].*
-RewriteRule ^foo\.html$         foo.20.html          [L]
-
-RewriteRule ^foo\.html$         foo.32.html          [L]
-
 -
-
- -
- -
- - Miroir dynamique - -
-
Description :
- -
-

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 mirror 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 webcopy 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).

-
- -
Solution :
- -
-

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é Mandataire (drapeau - [P] ou [proxy]) :

- -
-RewriteEngine  on
-RewriteBase    /~quux/
-RewriteRule    ^page-convoitée/(.*)$  http://www.tstimpreso.com/page-convoitée/$1  [P]
-
 - -
-RewriteEngine  on
-RewriteBase    /~quux/
-RewriteRule    ^usa-news\.html$   http://www.quux-corp.com/news/index.html  [P]
-
 -
-
- -
- -
- - Miroir dynamique inverse - -
-
Description :
- -
...
- -
Solution :
- -
-
-RewriteEngine on
-RewriteCond   /miroir/du/site-distant/$1           -U
-RewriteRule   ^http://www\.site-distant\.com/(.*)$ /miroir/du/site-distant/$1
-
 -
-
- -
- -
- - Récupérer des données manquantes depuis l'Intranet - -
-
Description :
- -
-

C'est une méthode astucieuse permettant de faire - fonctionner virtuellement un serveur web d'entreprise - (www.quux-corp.dom) sur - l'Internet (extérieur à l'entreprise), tout en maintenant et - conservant dans la réalité ses données sur un serveur web - (www2.quux-corp.dom) 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.

-
- -
Solution :
- -
-

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 :

- -
-ALLOW serveur www.quux-corp.dom Port >1024 -->
-serveur www2.quux-corp.dom Port 80
-DENY  serveur *                 Port *     -->
-serveur www2.quux-corp.dom Port 80
-
 - -

Il vous suffit d'adapter ces règles à la syntaxe de votre - pare-feu. Nous pouvons maintenant définir les règles de - mod_rewrite qui serviront à récupérer les - données manquantes en arrière-plan via la fonctionnalité de - mandataire :

- -
-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}       !-f
-RewriteCond %{REQUEST_FILENAME}       !-d
-RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P]
-
 -
-
- -
- -
- - Répartition de charge - -
-
Description :
- -
-

Supposons que nous voulions répartir la charge du trafic - vers www.example.com entre les serveurs - www[0-5].example.com (un total de 6 serveurs). - Comment y parvenir ?

-
- -
Solution :
- -
-

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 mod_rewrite - :

- -
    -
  1. - Round-Robin (tourniquet) DNS - -

    La méthode de répartition de charge la plus simple - consiste à utiliser le "DNS round-robin" - (rotation d'adresses) de - BIND. Vous devez seulement enregistrer les - serveurs www[0-9].example.com de manière - habituelle dans votre DNS à l'aide d'enregistrements de - type A (adresse), comme suit :

    - -
    -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
-
     - -

    Puis vous ajoutez les entrées suivantes :

    - -
    -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
-
     - -

    Maintenant, lors de la résolution de - www.example.com, BIND renvoie - www0-www5 - 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 - www.example.com en un des - wwwN.example.com, 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.

    -
    2. - -
  2. - Répartition de charge basée sur DNS - -

    Une méthode de répartition de charge sophistiquée basée - sur DNS consiste à utiliser le programme - lbnamed que l'on peut trouver à - http://www.stanford.edu/~riepel/lbnamed/. - 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.

    -
    3. - -
  3. - Round-Robin basé sur la fonctionnalité de - mandataire - -

    Dans cette variante, nous utilisons - mod_rewrite et sa fonctionnalité de - mandataire. Tout d'abord, nous définissons - www0.example.com comme un autre nom de - www.example.com en ajoutant l'entrée

    - -
    -www    IN  CNAME   www0.example.com.
-
     - -

    dans le DNS. Puis nous définissons - www0.example.com 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 (www1-www5). Pour y - parvenir, nous définissons tout d'abord un jeu de règles - qui contacte un script de répartition de charge - lb.pl pour toutes les URLs.

    - -
    -RewriteEngine on
-RewriteMap    lb      prg:/chemin/vers/lb.pl
-RewriteRule   ^/(.+)$ ${lb:$1}           [P,L]
-
     - -

    Puis nous écrivons lb.pl :

    - -
    -#!/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##
-
     - - Une dernière remarque : à quoi cela sert-il ? - www0.example.com, 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. -
    4. - -
  4. - Répartiteur de charge dédié - -

    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 - liste de diffusion lb-l - est un bon point de départ pour vos recherches.

    -
    5. -
-
-
- -
- -
- - Nouveau type MIME, nouveau service - -
-
Description :
- -
-

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 PATH_INFO et - QUERY_STRINGS) en entrée. Tout d'abord, - définissons un nouveau type de fichier ayant pour extension - .scgi (pour CGI sécurisé) qui sera associé pour - traitement au programme populaire cgiwrap. 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 - /u/user/foo/bar.scgi. Mais cgiwrap - nécessite des URLs de la forme - /~user/foo/bar.scgi/. La règle suivante apporte - la solution :

- -
-RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ...
-... /interne/cgi/utilisateur/cgiwrap/~$1/$2.scgi$3  [NS,T=application/x-http-cgi]
-
 - -

Ou considérons ces autres programmes attractifs : - wwwlog (qui affiche le journal des accès - access.log pour un sous répertoire correspondant - à une URL) et wwwidx (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 swwidx depuis - /u/user/foo/ via un hyperlien vers

- -
-/internal/cgi/user/swwidx?i=/u/user/foo/
-
 - -

ce qui n'est pas satisfaisant, car nous devons expliciter - à la fois la localisation du répertoire - et 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.

-
- -
Solution :
- -
-

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 :

- -
-RewriteRule   ^/([uge])/([^/]+)(/?.*)/\*  /interne/cgi/utilisateur/wwwidx?i=/$1/$2$3/
-RewriteRule   ^/([uge])/([^/]+)(/?.*):log /interne/cgi/utilisateur/wwwlog?f=/$1/$2$3
-
 - -

Et maintenant l'hyperlien qui renvoie vers - /u/user/foo/ se réduit à

- -
-HREF="*"
-
 - -

qui est automatiquement transformé en interne en

- -
-/internal/cgi/user/wwwidx?i=/u/user/foo/
-
 - -

Une approche similaire permet d'invoquer le programme CGI - du journal des accès lorsque l'hyperlien :log est - utilisé.

-
-
- -
- -
- - Régéneration de contenu à la volée - -
-
Description :
- -
-

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 - cron) ne supprime les - contenus statiques. Les contenus sont ensuite actualisés.

-
- -
Solution :
- -
- A cet effet, on utilise le jeu de règles suivant : - -
-# Cet exemple n'est valable que dans un contexte de répertoire
-RewriteCond %{REQUEST_FILENAME}   !-s
-RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]
-
 - -

Ainsi, une requête pour page.html entraîne - l'exécution interne de la page page.cgi - correspondante si page.html n'existe pas - ou possède une taille de fichier nulle. L'astuce réside ici - dans le fait que page.cgi est un script CGI - qui (en plus de STDOUT) écrit sa sortie dans le - fichier page.html. Une fois le script exécuté, le - serveur sert la page page.html fraîchement - générée. Si le webmaster - veut actualiser les contenus, il lui suffit de supprimer le - fichier page.html (le plus souvent via une tâche - de cron).

-
-
- -
- -
- - Actualisation automatique d'un document - -
-
Description :
- -
-

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 ?

-
- -
Solution :
- -
-

Non ! Nous allons pour cela combiner la fonctionnalité MIME - multipart, la fonctionnalité NPH du serveur web et la - puissance de mod_rewrite pour la manipulation - d'URLs. Tout d'abord, nous définissons une nouvelle - fonctionnalité pour les URLs : l'ajout de - :refresh à toute URL fait que la 'page' est - actualisée chaque fois que la ressource est mise à jour dans - le système de fichiers.

- -
-RewriteRule   ^(/[uge]/[^/]+/?.*):refresh  /interne/cgi/apache/nph-refresh?f=$1
-
 - -

Nous appelons maintenant cette URL

- -
-/u/foo/bar/page.html:refresh
-
 - -

ce qui entraîne en interne l'invocation de l'URL

- -
-/interne/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
-
 - -

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.

- -
-#!/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##
-
 -
-
- -
- -
- - Hébergement virtuel de masse - -
-
Description :
- -
-

La fonctionnalité VirtualHost 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.

-
- -
Solution :
- -
-

Pour fournir cette fonctionnalité avec - mod_rewrite, on fait correspondre à notre espace de - nommage la page web ou même le répertoire complet distants en - utilisant la fonctionnalité Mandataire - (drapeau [P]) :

- -
-##
-##  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
-
 - -
-##
-##  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}}]
-    :
-
 -
-
- -
- -
- - Interdiction d'hôtes - -
-
Description :
- -
-

Comment interdire l'accès à notre serveur à une liste - d'hôtes ?

-
- -
Solution :
- -
-

Pour Apache >= 1.3b6 :

- -
-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]
-
 - -

Pour Apache <= 1.3b6 :

- -
-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
-
 - -
-##
-##  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  -
-
 -
-
- -
- -
- - Interdiction du mandataire - -
-
Description :
- -
-

Comment interdire l'utilisation du mandataire d'Apache pour - un certain hôte, ou même seulement pour un utilisateur - de cet hôte ?

-
- -
Solution :
- -
-

Nous devons tout d'abord nous assurer que - mod_rewrite arrive après(!) - mod_proxy dans le fichier de configuration - lors de la compilation du serveur web Apache. De cette façon, - il est appelé avant mod_proxy. Nous - pouvons ensuite définir cette règle pour une interdiction - dépendant de l'hôte :

- -
-RewriteCond %{REMOTE_HOST} ^hôte-à-rejeter\.mon-domaine\.com$
-RewriteRule !^http://[^/.]\.mon-domaine.com.*  - [F]
-
 - -

...et celle-ci pour une interdiction dépendant de - utilisateur@hôte :

- -
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}  ^utilisateur-à-
-rejeter@hôte-à-rejeter\.mon-domaine\.com$
-RewriteRule !^http://[^/.]\.mon-domaine.com.*  - [F]
-
 -
-
- -
- -
- - Variante particulière d'authentification - -
-
Description :
- -
-

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 mod_auth).

-
- -
Solution :
- -
-

On définit une liste de conditions de réécriture pour - interdire l'accès à tout le monde, sauf aux utilisateurs - autorisés :

- -
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^ami1@client1.quux-corp\.com$
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^ami2@client2.quux-corp\.com$
-RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^ami3@client3.quux-corp\.com$
-RewriteRule ^/~quux/seulement-pour-les-amis/      -                                 [F]
-
 -
-
- -
- -
- - Redirection basée sur le référent - -
-
Description :
- -
-

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 ?

-
- -
Solution :
- -
-

On utilise le jeu de règles vraiment astucieux suivant :

- -
-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]
-
 - -

... en association avec la table de réécriture - correspondante :

- -
-##
-##  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/
-
 - -

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 à "-"), ou vers une - URL spécifique (lorsqu'une URL est définie dans la table de - correspondances comme second argument).

-
-
- -
- - - diff --git a/docs/manual/style/build.properties b/docs/manual/style/build.properties index b123dfb956..3b8ffef688 100644 --- a/docs/manual/style/build.properties +++ b/docs/manual/style/build.properties @@ -1,4 +1,6 @@ # This file contains version specific properties -# No xml files yet -# noxml.fr = upgrading.html.fr +# No xml files yet or anymore +noxml.fr = + rewrite/rewrite_guide.html.fr + rewrite_guide_advanced.html.fr