Advanced Techniques with 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: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]
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 :

Parfois, 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 était 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

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