La mise en place de l’url-rewriting, technique qui consiste à réécrire des url complexes sous une forme lisible, repose sur un ensemble de petites règles simples. Celles-ci, bien assimilées et utilisés, devraient permettre de pallier aux inconvénients créés par des urls incompréhensibles.

Le pilotage du serveur http est réalisé à l’aide d’un fichier .htaccess qui est déposé à la racine du site ou du répertoire « rewrité ». Mais, de simples caractères mal interprété peuvent conduire tout simplement à la non interprétation complète du fichier et donc paralyser complètement l’exécution de l’url rewriting

Prenons par exemple l’utilisation de la commande « RewriteRule » dont la syntaxe pour le serveur Apache (source documentation) la plus minimaliste est :

Options +FollowSymLinks
RewriteEngine on
RewriteRule ^nouveau-nom.html$ url-complexe-et-illisible [L]

Les deux premières lignes de commande débutent le début de l’url-rewriting. Pour désactiver cet url-rewriting, il suffit simplement de remplacer RewriteEngineOn par RewriteEngineOff

L’explication de la troisième ligne de commande RewriteRule (à répéter autant de fois que nécessaire, par exemple, pour les différents éléments d’une barre de navigation) est :

  • RewriteRule commande la ré-écriture d’une url
  • ^ est une convention de lisibilité marquant le début du nouveau nom de page à afficher ou à utiliser
  • nouveau-nom.html est positionné a partir du répertoire du fichier où est déposé le fichier .htacess
  • $ est une convention de lisibilité marquant la fin du nouveau nom de page à afficher ou à utiliser
  • url-complexe-et-illisible est l’url qui, est positionné a partir du répertoire du fichier où est déposé le fichier .htacess, est généré par l’outil de gestion du site
  • [L] indique au serveur d’arrêter la lecture du fichier .htaccess si la règle de cette ligne est applicable

Ici, c’est surtout la règle d’écriture du nouveau-nom qui peut porter préjudice. L’emploi des caractères accentués est par exemple complètement à bannir car il génère une erreur interne du serveur apache.

Un exemple simple sur le serveur «www.exemple-de-site.com » qui contient la page http://www.ex-de-site.com/index.php?option=com_content&task=category§ionid=4&id=22&Itemid=343&menu=menu_règles_génériques

La tentation serait grande d’affecter comme nouveau nom à cette page : règles-génériques.html. Mais la bonne règle de nommage pourrait être :

RewriteRule ^regles-generiques.html$ index.php?option=com_content&task=category§ionid=4&id=22&Itemid=343&menu=menu_règles_génériques [L]

En pratique, pour tester la validité de son fichier sans planter son serveur, c’est préférable d’utiliser un sous-répertoire de test. En effet, si le fichier est invalide, même l’appel de l’url du site, tel que http://www.exemple-de-site.com renverra, avec un fichier .htaccess incorrect déposé à sa racine, un code d’erreur interne. Et donc le site sera innacessible pour tout appel.

Il suffit tout simplement de déposer son fichier .htaccess dans ce sous-répertoire avec un fichier test.html affichant, au hasard -) : HelloWord

Le résultat du test est simple :

Si http://www.”votre-site”.com/test.html renvoit «HelloWord», la syntaxe minimale est bonne, sinon, rechercher les caractères accentués, les espaces entre le nom et .html, les caractères spéciaux …