Techniques avancées avec mod_rewrite - Serveur HTTP Apache Version 2.4

Serveur HTTP Apache Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > Rewrite

# Techniques avancées avec 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

## 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
  # etc ...`

  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` et le RewriteMap HowTo 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:servers}/$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]
      RewriteRule   "^foo\.html$"             "foo.night.html"

  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 :

  Nous voulons parfois 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 était concernée par cette réécriture. Pour ce faire, 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"

  Notez que les variables d'environnement ne survivent pas à une redirection externe. Vous devez alors utiliser le drapeau [CO] pour définir un cookie. Pour les redirections de niveau répertoire et htaccess où la substitution finale est traitée en tant que redirection interne, les variables d'environnement du tour de réécriture précédent sont préfixées par "REDIRECT_".

Langues Disponibles: en | fr