Un moteur de réé­cri­ture, de l’anglais Rewrite Engine (rewrite = réécrire, engine = moteur), est un composant de logiciel Web qui permet de réécrire des URLs (Uniform Resource Locators) ou de les trans­fé­rer. Le moteur le plus connu est mod_rewrite du serveur HTTP Apache. D’autres serveurs Web existent tels que nginx ou lighttpd dont les fonctions sont si­mi­laires. Ces com­po­sants de logiciel in­ter­vien­nent par exemple lorsque que des URLs dy­na­miques peu fiables, comme ceux parfois utilisés par les systèmes de gestion de contenus, doivent être réécrits pour être davantage adaptés à la navigation. Les raisons sont évidentes. Il est complexe pour un in­ter­naute de retenir une URL tel que "http://exemple.com/a/index.php?title=ti­tre­de­page". Le moteur de réé­cri­ture permet donc de créer une adresse plus simple tout en con­ser­vant sa source. Par exemple : "http://exemple.com/article/ti­tre­de­page". Un in­ter­naute peut ainsi utiliser cette URL pour charger le site Internet en question. Dès que la requête est entrée, le module Rewrite Engine modifie au­to­ma­ti­que­ment l’URL dans le schéma utilisé en interne par le serveur "http://exemple.com/a/index.php?title=ti­tre­de­page". C’est ainsi que le module Rewrite Engine crée une sorte de couche d’abs­trac­tion entre les URLs qui utilisent le projet Web en interne et les URLS qui sont visibles sur le Web. Il permet d’offrir un système d’adressage convivial et uniforme tout en tenant compte des exigences tech­niques internes. En interne, il est possible de continuer à utiliser l‘adresse dynamique pa­ra­mé­trée, les in­ter­nautes ont quant à eux accès à une adresse statique. L’avantage est que ces URLs demeurent actives même si des chan­ge­ments internes sont mis en place dans la hié­rar­chie des fichiers. En outre, ces moteurs de réé­cri­ture per­met­tent aux ad­mi­nis­tra­teurs de sites Internet de mettre en place sous certaines con­di­tions des trans­ferts d’adresses. Il est, par exemple, possible de créer des re­di­rec­tions en se basant sur l’identité d’un agent uti­li­sa­teur ou sur l’adresse IP du client concerné, le but est alors de mettre en œuvre un ciblage géo­gra­phique ou d’optimiser un site Internet pour le rendre ac­ces­sible sur tous les supports. En règle générale, une re­di­rec­tion 301 apparaît alors, ce qui garantit qu’une version du site soit toujours sau­ve­gar­dée dans l’index du moteur de recherche, et ce in­dé­pen­dam­ment des autres pendants dédiés aux appareils mobiles ou écrits dans d’autres langues. Il est pri­mor­dial de garder ses distances face aux pratiques de cloaking dont le but est d’améliorer le po­si­tion­ne­ment d’un site en créant deux versions de pages, une destinée aux robots des moteurs de recherche et l’autre destinée à l’uti­li­sa­teur final.

Exemples d‘ap­pli­ca­tion

En ce qui concerne la ma­ni­pu­la­tion d’URLs, le module Rewrite Engine fournit diverses commandes qui sont intégrées au logiciel de serveur Web. C’est ainsi que mod_rewrite peut être utilisé dans un conteneur de ré­per­toire au sein de httpd.conf, dans une partie d’hé­ber­ge­ment virtuel ou à l’intérieur d’un fichier .htaccess. Une réé­cri­ture d’URL sera noté nginx dans le fichier de con­fi­gu­ra­tion /etc/nginx/nginx.conf. Le fichier /etc/lighttpd.conf est dis­po­nible dans la con­fi­gu­ra­tion Vir­tual­Host sous lighttpd. i

Pour réécrire l’adresse dynamique "http://exemple.com/a/index.php?title=ti­tre­de­page" via le moteur de réé­cri­ture dans l’URL statique "http://exemple.com/article/ti­tre­de­page", plusieurs commandes sont ac­tion­nées dans les serveurs Apache nginx et lighttpd.

Rewrite Engine sous Apache

Afin d’utiliser mod_rewrite sous Apache, il convient que le module de réé­cri­ture soit activé via la commande Re­wri­teEn­gine on. Par la suite apparaît Re­wri­te­Rule qui définit les ins­truc­tions pour la réé­cri­ture de l’URL en utilisant ce qu’on appelle les ex­pres­sions ré­gu­lières (« regular ex­pres­sions », Regex) : 

RewriteEngine on
RewriteRule ^/article/(.*)$ /a/index.php?title=$1

Si la commande Re­wri­te­Rule définit une re­di­rec­tion, cette dernière doit alors comporter deux pa­ra­mètres : le modèle de recherche ainsi que le modèle cible.

  • Modèle de recherche : ce paramètre décrit les URLs qui doivent être redirigés. C’est ainsi qu’une condition est définie sous la forme d’une suite de signes. Si cette condition est remplie, une re­di­rec­tion se produit vers un URL en se basant sur le modèle cible. L’exemple actuel serait le modèle de recherche de l’extrait suivant du Re­wri­te­Rule ^/artikel/(.*)$.
  • Modèle de cible : ce paramètre décrit l’URL vers lequel la direction doit être faite. Si cette dernière est con­fi­gu­rée au niveau du serveur, l’URL complet est alors remplacée. En ce qui concerne le ré­per­toire qui se trouve dans le fichier .htaccess ou au sein de httpd.conf, le chemin est uni­que­ment remplacé en partant du ré­per­toire courant. Dans notre exemple, le modèle cible comprend cet extrait du Re­wri­te­Rule /a/index.php?title=$1.

Le tableau suivant vous explique les ex­pres­sions ré­gu­lières utilisées dans notre exemple :

Ex­pres­sions ré­gu­lières Ex­pli­ca­tions
^ Décrit le début d’une chaîne.
$ Marque la fin d’une chaîne.
(.*) Un caractère de rem­pla­ce­ment pour une suite de signes ar­bi­traire au sein d’un URL. Les pa­ren­thèses sau­ve­gar­dent la suite de signes dans une variable.
$1 Une variable qui permet d’avoir accès aux valeurs mises en cache sau­ve­gar­dées entre pa­ren­thèses.

Le module Re­wri­te­Rule ^/article/(.*)$ /a/index.php?title=$1 définit en général que cet extrait est réécrit dans le schéma d’URL dynamique /a/index.php?title=$1 pour ce qui est de tous les URLs com­men­çant avec la chaine /articlel/(.*).  $1 vaut pour la suite de signes qui cor­res­pond au caractère de rem­pla­ce­ment. Si un in­ter­naute entre l’URL statique "http://exemple.com/article/ti­tre­de­page" dans son na­vi­ga­teur, le moteur de recherche le réécrit alors en une adresse dynamique "http://exemple.com/a/index.php?title=ti­tre­de­page" au niveau interne en se basant sur mod_rewrite et en la rendant invisible aux in­ter­nautes. Le caractère de rem­pla­ce­ment (.*) et la variable $1 cor­res­pon­dent dans ce cas à la suite de signe « ti­tre­de­page ». Lorsque la réé­cri­ture d’une URL est associée à certaines options qui com­man­dent le com­por­te­ment du mod_rewrite, ces dernières sont notées entre crochets derrière le Re­wri­te­Rule et séparées par des virgules (si plusieurs options sont prises en compte). C’est ainsi que les re­di­rec­tions externes via le code de statuts HTTP sont réalisées en externe. Le tableau qui suit montre une sélection d’options pour la commande Re­wri­te­Rule. Vous en trouverez une liste complète sur le site officiel de la fondation du logiciel Apache.

Options Drapeaux de réé­cri­ture Fonctions
Redirect R Le drapeau de réé­cri­ture [R] ordonne au serveur Web d’exécuter un transfert externe via le code de statuts HTTP 302. Si un autre code de statuts est envoyé, ce dernier est alors ajouté au drapeau avec un signe égal. Par exemple [R=301].
Forbidden F Ordonne au serveur Web d’envoyer au na­vi­ga­teur le code de statuts HTTP 403 (Forbidden).
Gone G Ordonne le serveur Web d’envoyer le code de statuts HTTP 410 au na­vi­ga­teur et marque le site Internet en question comme inac­ces­sible.
Last L Ordonne le serveur Web de ne plus rien engager suite à la commande Re­wri­te­Rule actuelle.
Nocase NC En vérifiant si une URL remplit les con­di­tions de la réé­cri­ture ou non, les ma­jus­cules et les mi­nus­cules ne sont pas prises en compte.
Chain C Le prochain Re­wri­te­Rule est pris en compte seulement si la condition actuelle est convient.

En se basant sur une telle option, il est possible de mettre une re­di­rec­tion externe en place via le code de statuts HTTP suivant : 

RewriteEngine On
RewriteRule ^vieillepage.html$ /nouvellepage.html [R=301]

Outre la commande Re­wri­te­Rules, le module mod_rewrite peut également être défini par Re­wri­te­Conds avec lesquels les ad­mi­nis­tra­teurs de sites Internet fixent des con­di­tions sup­plé­men­taires qu’il faut remplir pour engager une réé­cri­ture d’URL.

La syntaxe d’une commande Re­wri­te­Cond cor­res­pond à la cons­truc­tion suivante et est noté devant la commande Re­wri­te­Rule :

RewriteCond TESTSTRING CONDITION

La chaine test comprend en règle générale des variables de serveur définies via un signe de pour­cen­tage et des accolades, comme dans l’exemple %{HTTP_HOST}. Le tableau suivant montre une sélection de variables de serveurs :

Variables de serveur Ex­pli­ca­tions
HTTP_USER_AGENT Fait référence au client qui est utilisé pour l’accès au serveur. La variable est utilisée en générale pour que les divers na­vi­ga­teurs disposent d’un site Internet optimisé.
HTTP_HOST Fait référence au nom d’hôte. Ce dernier peut com­prendre des valeurs telles que domain.com, subdomain.domain.com ou l’adresse IP.
SERVER_PORT Fait référence au port concerné (par exemple 80 pour HTTP ou 443 pour HTTPS). Cette variable permet à l’ad­mi­nis­tra­teur de site Internet de rediriger l’in­ter­naute vers une connexion sécurisée.
REMOTE_ADDR Fait référence à l’adresse IP d’un in­ter­naute qui a accès au serveur Web. Cette variable est entre autre utilisé pour bloquer l’accès au spams.

L’exemple suivant montre une commande Re­wri­te­Cond, qui relie une Re­wri­te­Rule à l’adresse IP d’un in­ter­naute qui dispose d’un accès : 

RewriteCond %{REMOTE_ADDR} 173.45.68.79

Réé­cri­ture d’URL sous nginx

Le serveur Web nginx soutient également la réé­cri­ture native d’URL. Tout cela est mis en place grâce aux ex­pres­sions ré­gu­lières. Pour réécrire des URLs, une commande doit cor­res­pondre à la syntaxe nginx et être insérée dans un bloc { [...] } dans le fichier de con­fi­gu­ra­tion du serveur Web /etc/nginx/nginx.conf.

location /article {
 rewrite ^/article/(.*)$ /index.php?title=$1 last;
}

L’ad­mi­nis­tra­teur de site Internet indique avec location /article que la réé­cri­ture d’URL fait référence au ré­per­toire article. Les ex­pres­sions ré­gu­lières pour la réé­cri­ture cor­res­pon­dent à celles qui in­ter­vien­nent également au niveau des serveurs Web Apache et qui com­men­cent par la commande rewrite. Le drapeau last indique que la réé­cri­ture doit avoir lieu en interne et sans re­di­rec­tion. Autrement, les drapeaux restent à dis­po­si­tion pour une re­di­rec­tion tem­po­raire ou durable.

Drapeaux Ex­pli­ca­tions
last Les URLs sont réécrits en interne. Aucune re­di­rec­tion ne suit.
redirect L’uti­li­sa­teur est redirigé par une re­di­rec­tion tem­po­raire 302 vers une nouvelle URL.
permanent L’uti­li­sa­teur est redirigé par une re­di­rec­tion durable 301 vers une nouvelle URL.

Si aucun drapeau n’est mis en place, nginx indique de manière au­to­ma­tique le code d’erreur HTTP 500.

Réé­cri­ture d’URL sous lighttpd

Sous lighttpd, l’écriture d’une URL est réalisée en se basant sur la fonction url.rewrite-TYP. Le caractère de rem­pla­ce­ment TYP vaut pour plusieurs pos­si­bi­li­tés de con­fi­gu­ra­tions de réé­cri­ture.

Pos­si­bi­li­tés de con­fi­gu­ra­tions de réé­cri­ture Ex­pli­ca­tion
url.rewrite-once Unique réé­cri­ture d’URL. Si le modèle de recherche a été trouvé et l’URL a été récrit en fonction de ce dernier, aucune re­di­rec­tion n’a lieu.
url.rewrite-repeat Con­trai­re­ment à la commande url.rewrite-once, il est possible, grâce à url.rewrite-repeat, de répéter d’autres réé­cri­tures.

Dans le cadre d’une réé­cri­ture d’URL sous Apache, les ex­pres­sions ré­gu­lières in­ter­ve­nantes sont les même que sous Apache, ce qui induit que la syntaxe cor­res­pond es­sen­tiel­le­ment au modèle déjà connu. 

url.rewrite-once = (
 "^/article/(.*)$" => "/index.php?title=$1"
)

Si une re­di­rec­tion externe a lieu à la place d’une réé­cri­ture interne, lighttpd ne fera alors pas appel au module de réé­cri­ture (Rewriting) mais à celui de la re­di­rec­tion (Redirect).

Réé­cri­ture sous Microsoft IIS

La pla­te­forme Microsoft Internet In­for­ma­tion Services (IIS) ne possède à l’origine aucun moteur de réé­cri­ture. Ce dernier peut être après coup ajouté au serveur Web avec le module de réé­cri­ture d’URL 2.0 Microsoft pour IIS 7 (x64). C’est ainsi que les uti­li­sa­teurs de Microsoft peuvent mettre de telles URLs à la dis­po­si­tion de leur in­ter­nautes sans avoir à toucher à la gestion interne des données. L’extension de réé­cri­ture d’URL s’intègre après le té­lé­char­ge­ment di­rec­te­ment à l’interface du ges­tion­naire IIS où les modules Re­wri­tin­gRules sont entrés via une interface graphique. Les modules de réé­cri­tures d’URL 2.0 IIS utilisent également des ex­pres­sions ré­gu­lières dans le but de définir des modèles de recherche et cible d’URL.

Réé­cri­ture d’URLs et op­ti­mi­sa­tion pour les moteurs de recherche

Les fonc­tion­na­li­tés de mod_rewrite ainsi que ses pendants dans les autres systèmes de serveurs Web re­pré­sen­tent un intérêt pour l’op­ti­mi­sa­tion sur les moteurs de recherche.  C’est ainsi que les URLs dites « con­vi­viales » sont con­si­dé­rées comme des facteurs im­por­tants pour le SEO. Par con­sé­quent, les ad­mi­nis­tra­teurs de sites Internet bé­né­fi­cient des effets indirects de ces re­di­rec­tions et ré­cri­tures. Con­trai­re­ment aux pa­ra­mètres cryptés, ces adresses URLS réécrites per­met­tent aux in­ter­nautes de com­prendre vers quoi se mène un lien. Par ailleurs, ils peuvent être utilisés pour mettre les in­ter­nautes en confiance et, sous certaines cir­cons­tances, pour faire croître le taux de clics. Dans un second temps, les requêtes sur Internet sont inscrites en gras dans les résultats de recherche, ce qui incite l’uti­li­sa­teur à cliquer.

Aller au menu principal