Serveur Apache HTTP Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > Rewrite

# Advanced Techniques with mod_rewrite

Langues Disponibles: en | fr

Cette traduction peut être périmée. Vérifiez la version anglaise pour les changements récents.

Ce document complète la documentation de référence du module `mod_rewrite`. Il présente un certain nombre de techniques avancées quant à l'utilisation de mod_rewrite.

Notez que la plupart des exemples ne fonctionneront pas en l'état dans la configuration particulière de votre serveur ; il est donc important de bien comprendre leur fonctionnement, plutôt que de simplement les copier/coller dans votre configuration.

### Voir aussi

- Documentation du module
- Introduction à mod_rewrite
- Redirection et remise en correspondance
- Contrôler l'accès
- serveurs virtuels
- serveurs mandataires
- Utilisation de RewriteMap
- Quand ne pas utiliser mod_rewrite

- Commentaires

## Distribution de la charge entre plusieurs serveurs d'arrière-plan en fonction de l'adresse IP

Description :

  La fragmentation ou "sharding" est une technique courante de distribution de la charge du serveur ou de l'espace de stockage. Quand on utilise cette méthode, un serveur frontal utilise l'URL pour répartir de manière appropriée les utilisateurs et objets entre différents serveurs d'arrière-plan.

Solution :

  On maintient une table de correspondance entre utilisateurs et serveurs cibles dans des fichiers externes. Ces derniers se présentent comme suit :

  `utilisateur1 serveur_physique_utilisateur1
  utilisateur2 serveur_physique_utilisateur2
  : :`

  Tout ceci est enregistré dans un fichier `correspondances-utilisateurs-serveurs`. Le but est de faire correspondre

  `/u/utilisateur1/chemin`

  avec

  `http://serveur_physique_utilisateur1/u/utilisateur/chemin`

  il n'est ainsi pas nécessaire que tous les chemins URL soient valides sur tous les serveurs physiques d'arrière-plan. Le jeu de règles suivant fait tout ceci pour nous, en s'appuyant sur les fichiers de correspondances, en supposant que serveur0 est un serveur par défaut qui sera utilisé lorsqu'un utilisateur ne possèdera pas d'entrée dans la table de correspondances :

      RewriteEngine on
      RewriteMap      users-to-hosts   txt:/path/to/map.users-to-hosts
      RewriteRule   ^/u/([^/]+)/?(.*)   http://${users-to-hosts:$1|server0}/u/$1/$2

Voir la documentation de `RewriteMap` pour une description plus approfondie de la syntaxe de cette directive.

## Régéneration de contenu à la volée

Description :

  Nous voulons générer du contenu de manière dynamique, mais le conserver de manière statique lorsqu'il a été généré. La règle suivante vérifie l'existence du fichier statique, et le génère s'il est absent. Les fichiers statiques peuvent être supprimés périodiquement si on le désire (par exemple via cron), et seront régénérés à la demande.

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_URI}   !-U
      RewriteRule ^(.+)\.html$          /regenerate_page.cgi   [PT,L]

  L'opérateur `-U` permet de déterminer si la chaîne de test (dans ce cas `REQUEST_URI`) est une URL valide. Pour ce faire, il utilise une sous-requête. Si cette sous-requête échoue, ou en d'autres termes, si la ressource demandée n'existe pas, cette règle invoque le programme CGI `/regenerate_page.cgi` qui génère la ressource demandée et la sauvegarde dans le répertoire des documents, de façon à ce qu'une copie statique puisse être servie lors d'une demande ultérieure.

  De cette façon, les documents qui ne sont pas mis à jour régulièrement peuvent être servis sous une forme statique. Si ces documents doivent être réactualisés, on peut les supprimer du répertoire des documents, et ils seront ainsi régénérés à la prochaine demande.

## Répartition de charge

Description :

  Nous voulons répartir la charge de manière aléatoire entre plusieurs serveurs en utilisant mod_rewrite.

Solution :

  Pour y parvenir, nous allons utiliser la directive `RewriteMap` et une liste de serveurs.

      RewriteEngine on
      RewriteMap lb rnd:/path/to/serverlist.txt
      RewriteRule ^/(.*) http://${lb:serveurs}/$1 [P,L]

  `liste-serveurs.txt` contiendra la liste des serveurs :

  `## liste-serveurs.txt
  serveurs un.example.com|deux.example.com|trois.example.com
  `

  Si vous voulez qu'un serveur se voit confier d'avantage de charge que les autres, faites le figurer plusieurs fois dans la liste.

Discussion

  Apache possède un module de répartition de charge - `mod_proxy_balancer` - beaucoup plus souple et présentant plus de fonctionnalités dans ce domaine que mod_rewrite.

## Répertoires Home structurés

Description :

  Certains sites avec des milliers d'utilisateurs organisent les répertoires utilisateurs de manière structurée, c'est à dire que chaque répertoire utilisateur se trouve dans un sous-répertoire dont le nom commence (par exemple) par le premier caractère du nom de l'utilisateur. Ainsi, `/~larry/chemin` correspond à `/home/l/larry/public_html/chemin`, alors que `/~waldo/chemin` correspond à `/home/w/waldo/public_html/chemin`.

Solution :

  On utilise le jeu de règles suivant pour développer les URLs avec tilde selon l'organisation structurée précédente.

      RewriteEngine on
      RewriteRule   ^/~(([a-z])[a-z0-9]+)(.*)  /home/$2/$1/public_html$3

## 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".

Discussion :
  Cette technique fonctionne bien entendu pour tout autre caractère spécial que mod_rewrite, par défaut, code pour insertion dans une URL.

## Réécriture dépendant de l'heure

Description :

  Nous voulons servir des contenus différents selon l'heure du jour en utilisant 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.day.html [L]

  Avec cet exemple, l'URL `foo.html` renvoie le contenu de `foo.jour.html` durant le créneau horaire `07:01-18:59`, et le contenu de `foo.nuit.html` le reste du temps.

  `mod_cache`, les mandataires intermédiaires et les navigateurs peuvent chacun mettre en cache les réponses et ainsi afficher une des deux pages en dehors de la fenêtre de temps configurée. On peut utiliser `mod_expires` pour contourner ce problème. Il est cependant bien plus commode de servir un contenu dynamique, et de le personnaliser en fonction de l'heure du jour.

## Définir des variables d'environnement en fonction de certaines parties de l'URL

Description :

  Ici, nous voulons conserver une certaine forme de statut lorsqu'une réécriture a eu lieu. Par exemple, vous souhaitez consigner le fait que cette réécriture a eu lieu, et vous servir plus tard de cette information pour déterminer si une requête sera concernée par cette réécriture. Pour y parvenir, on peut utiliser une variable d'environnement.

Solution :

  Utiliser le drapeau [E] pour définir une variable d'environnement.

      RewriteEngine on
      RewriteRule   ^/cheval/(.*)   /poney/$1 [E=rewritten:1]

  Plus loin dans votre jeu de règles, vous pouvez vérifier le contenu de cette variable d'environnement via une directive RewriteCond :

      RewriteCond %{ENV:rewritten} =1

Langues Disponibles: en | fr

## Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.