Création de règles de redirection et de réécriture dans .htaccess sur le serveur web Apache

Lors de l’utilisation du serveur web Apache, les fichiers .htaccess (également appelés « fichiers de configuration distribués ») sont utilisés pour spécifier la configuration par répertoire, ou plus généralement pour modifier le comportement du serveur web Apache sans avoir à accéder directement aux fichiers d’hôtes virtuels (ce qui est généralement impossible par exemple, sur les hôtes partagés). Dans ce tutoriel, nous voyons comment nous pouvons établir des redirections d’URL et des règles de réécriture dans les fichiers .htaccess.

Dans ce tutoriel, vous allez apprendre :

• Fonctionnement des fichiers .htaccess
• Comment configurer des règles de réécriture d’URL dans des fichiers .htaccess à l’aide de la directive RewriteRule
• Comment configurer les règles de redirection d’URL dans les fichiers .htaccess à l’aide des directives Redirect et RedirectMatch

Création de règles de redirection et de réécriture dans .htaccess sur le serveur web Apache

Configuration logicielle requise et conventions utilisées

Devriez-vous utiliser des fichiers .htaccess ?

Comme nous l’avons déjà mentionné, l’utilisation de fichiers .htaccess n’est pas recommandée si vous pouvez opérer directement sur les fichiers de configuration de l’hôte virtuel, car cela ralentit le serveur Web Apache (lorsque la directive AllowOverride est utilisée pour autoriser l’utilisation de fichiers .htaccess, le serveur Web analyse chaque répertoire à leur recherche). Dans certaines situations, cependant, l’utilisation de fichiers .htaccess est la seule solution.

L’ensemble des directives qui peuvent être utilisées dans les fichiers .htaccess sont établies dans la configuration du site principal via la directive AllowOverride, à l’intérieur d’une strophe <Directory> ; Par exemple, pour permettre l’utilisation de toutes les directives possibles, nous écririons quelque chose comme :

<Directory /path/to/directory>
   AllowOverride All
</Directory>

Les instructions seront appliquées aux fichiers .htaccess trouvés dans le répertoire spécifié et tous ses sous-répertoires.

Pour que les directives que nous allons utiliser dans ce tutoriel fonctionnent, il faut activer les modules mod_alias et mod_rewrite Apache.

Redirections (mod_alias)

Comme spécifié précédemment, dans nos fichiers .htaccess, nous pouvons vouloir spécifier certaines règles de redirection, de sorte que lorsqu’une URL est demandée, le client est redirigé vers une autre.

Nous avons essentiellement deux façons d’effectuer l’opération : en utilisant les directives Redirect ou RedirectMatch. Quelle est la différence entre les deux ? Le premier nous permet d’établir une redirection basée sur des correspondances d’URL simples et simples ; Le premier fait fondamentalement la même chose mais est plus puissant, car avec lui, nous pouvons utiliser des expressions régulières.

La directive « Redirect »

Voyons quelques exemples d’utilisation de la directive redirect. Supposons que nous voulions rediriger l’ensemble de notre site :

Redirect 301 / https://url/to/redirect/to

Celui ci-dessus est un exemple assez « extrême ». Analysons la syntaxe. Comme première chose, nous avons spécifié la directive : Redirection.

La deuxième chose que nous avons fournie est le code HTTP à utiliser pour la redirection : il peut être fourni soit sous forme de statut numérique, soit sous la forme d’une chaîne de caractères.
Quelques exemples :

Dans l’exemple précédent, nous avons configuré une redirection permanente puisque nous avons utilisé le code HTTP 301. L’équivalent de cela serait :

Redirect permanent / https://url/to/redirect/to

Le type de redirection peut être complètement omis : lorsque c’est le cas, le code 302 (redirection temporaire) il est utilisé par défaut.

Le troisième argument que nous avons fourni dans la règle est le chemin absolu de la ressource « d’origine » qui doit être mis en correspondance. Dans ce cas, nous avons utilisé / qui est la racine du site, puisque nous voulons le rediriger complètement. Ici, le schéma et la partie hôte de l’URL doivent être omis.

Le quatrième argument est la « nouvelle » URL vers laquelle l’utilisateur doit être redirigé. Dans ce cas, comme nous l’avons fait dans l’exemple ci-dessus, nous pouvons utiliser une URL complète, y compris le schéma et l’hôte, ou les omettre et n’utiliser qu’un chemin d’accès : dans ce dernier cas, elle serait considérée comme faisant partie du même site d’origine. Cet argument est obligatoire si le statut de redirection spécifié est compris entre 301 et 399, mais il doit être omis si le statut fourni n’est pas dans cette plage. C’est logique : imaginez que nous utilisions un statut 410 pour signaler que la ressource a disparu : cela n’aurait aucun sens de spécifier une URL de redirection. Dans ce cas, nous écririons simplement :

Redirect 410 /path/of/resource

La directive « RedirectMatch »

Avec la directive « Redirect », nous pouvons spécifier le chemin de l’URL à rediriger, mais il doit correspondre purement et simplement, comme il est spécifié. Que se passe-t-il si nous voulons effectuer quelque chose de plus complexe, comme par exemple rediriger les demandes pour tous les fichiers avec l’extension .html ? Dans ces cas, nous pouvons utiliser la directive RedirectMatch et utiliser une expression régulière. Voyons un exemple :

RedirectMatch 301 (.*)\.html$ $1.php

Dans l’exemple ci-dessus, nous avons redirigé toutes les demandes de fichiers .html sur notre site vers des fichiers portant le même nom et le même chemin, mais avec l’extension .php. Analysons la règle.

Comme toujours, la première chose que nous avons fournie est la directive, dans ce cas RedirectMatch. Après cela, comme nous l’avons fait précédemment, nous avons fourni le code HTTP à utiliser pour la redirection ; Ensuite, et c’est ce qui est intéressant, nous avons utilisé l’expression rationnelle (.*)\.html$.

Pour ceux d’entre vous qui sont déjà familiers avec l’expression régulière, cela devrait être immédiatement clair, mais voyons comment cela fonctionne : Le . (point) dans l’expression régulière correspond à tous les caractères : il est suivi du * qui établit que l’expression précédente doit être mise en correspondance 0 fois ou plus. L’expression est placée entre parenthèses, elle est donc groupée, et la partie de l’URL qui lui correspond peut être référencée ultérieurement via la variable $1 (plusieurs groupes peuvent être utilisés – ils sont 'nommés' progressivement, donc par exemple pour correspondre au deuxième groupe, nous pouvons utiliser $2). Après la partie de l’expression entre parenthèses, nous avons spécifié que le chemin doit se terminer par .html : vous pouvez voir que nous avons échappé le . avec une barre oblique inverse pour qu’il soit mis entre parenthèses
être mis en correspondance littéralement. Enfin, nous avons utilisé $ pour correspondre à la fin de la ligne.

Comme argument pour l’URL de redirection, nous avons utilisé $1.php. Comme nous l’avons déjà expliqué, $1 est utilisé pour référencer la partie de l’URL qui correspondait à l’expression régulière entre parenthèses (qui est le chemin complet moins l’extension .html), donc ce que nous faisons ici est essentiellement d’utiliser le même chemin mais avec l’extension .php.

Réécriture d’URL (mod_rewrite)

Les règles de réécriture d’URL peuvent être à la fois transparentes ou visibles par l’utilisateur. Dans le premier cas, l’utilisateur demande une page, et le serveur, en interne, traduit la demande sur la base de la règle fournie afin de servir la ressource : l’utilisateur ne remarque pas ce qui se passe, puisque l’URL dans son navigateur ne change pas. Dans le second cas, en revanche, nous réalisons pratiquement une redirection complète visible par l’utilisateur.

Commençons par le premier cas. Si nous voulons utiliser la réécriture d’URL, la première chose que nous devons faire (dans ce cas dans notre fichier .htaccess) est d’écrire la directive suivante :

RewriteEngine on

La directive RewriteEngine, comme son nom l’indique, est nécessaire pour modifier l’état du moteur de réécriture Apache. Dans l’exemple ci-dessus, nous l’avons activé ; Pour le désactiver, nous devons écrire :

RewriteEngine off

À titre d’exemple, supposons que nous ayons une ressource appelée page.html dans notre serveur, qui était auparavant accessible par l’URL simple : http://localhost/page.html. Imaginez maintenant que pour certaines raisons, nous renommions le fichier html, en newpage.html, mais pour des raisons évidentes, nous voulons que nos clients puissent toujours accéder à la ressource avec l’ancienne URL (peut-être l’ont-ils stockée dans les signets de leur navigateur). Ce que nous pourrions faire, c’est écrire la règle suivante, très
simple :

RewriteEngine on
RewriteRule ^page\.html /newpage.html

La syntaxe de la règle est très similaire à celle que nous avons utilisée pour la directive RedirectMatch : nous avons d’abord la directive elle-même, RewriteRule, puis nous avons le modèle utilisé pour la correspondance d’URL : il doit s’agir d’une regex. Après cela, nous avons la chaîne de substitution, qui est utilisée pour remplacer l’URL d’origine.

Là, un quatrième élément qui peut être utilisé dans la définition d’une RewriteRule sont les drapeaux, qui sont utilisés pour modifier le comportement du serveur Web lorsqu’une certaine règle est respectée.

Voyons un exemple : avec la règle que nous avons définie ci-dessus, comme nous l’avons déjà dit, aucune redirection ne se produit : l’URL dans la barre d’adresse du navigateur ne change pas. Si nous voulons qu’une redirection se produise, nous devons ajouter l’indicateur R à l’expression :

RewriteEngine on
RewriteRule ^page\.html /newpage.html [R]

Les drapeaux sont fournis entre parenthèses : dans ce cas précis, le drapeau R fait que la règle est interprétée comme une redirection. Il est même possible de spécifier le type de redirection qui doit avoir lieu, en spécifiant le code HTTP associé, par exemple :

RewriteRule ^page\.html /newpage.html [R=301]

Une autre chose courante à laquelle la réécriture d’URL est habituée, c’est d'"embellir » les URL, à des fins de référencement. Disons, par exemple, que nous avons un script PHP qui récupère d’une base de données un certain produit par son id fourni comme paramètre de requête dans
l’URL, par exemple :

http://localhost/products.php?id=1

Pour rendre la ressource disponible à l’URL http://localhost/products/1, nous pourrions écrire la règle suivante :

RewriteEngine on
RewriteRule ^products/([0-9]+)$ /products.php?id=$1

Avec l’expression régulière [0-9], nous faisons correspondre tous les chiffres, et avec le +, nous disons que l’expression précédente doit correspondre 1 ou plusieurs fois pour que la règle soit exécutée. L’expression correspondante est placée entre parenthèses, ce qui permet de référencer la partie correspondante de l’URL dans la chaîne « destination », en utilisant la variable $1. De cette façon, l’id du produit que nous fournissons dans l’URL « embellie », devient la valeur de la variable id dans la chaîne de requête.

Conditions de réécriture

Nous venons de voir comment, pour qu’une règle de réécriture soit appliquée, l’expression régulière doit correspondre à l’URL fournie par l’utilisateur. Dans le dernier exemple, nous avons vu comment l’URL http://localhost/products/1 peut être réécrite en interne pour http://localhost/products.php?id=1. Mais que se passe-t-il si le chemin spécifié par la nouvelle url fait référence à un « vrai » fichier existant sur le serveur ? Que se passe-t-il si, par exemple, /products/1 est un fichier normal et que nous voulons qu’il soit servi tel quel ? Dans de tels cas, nous pouvons utiliser la directive RewriteCond.

Avec la directive RewriteCond, nous spécifions une condition qui doit être respectée pour que la réécriture de l’URL ait lieu. Dans ce cas, par exemple, nous pouvons vouloir établir que si le fichier products/1 existe sur le serveur, la redirection
ne doit pas avoir lieu. Nous écririons :

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^products/([0-9]+)$ /products.php?id=$1

Nous utilisons la directive RewriteCond, avant la RewriteRule. La première chose que nous avons passée à la directive est la chaîne de test qui doit être mise en correspondance. Dans ce contexte, nous pouvons utiliser une série de variables de serveur prédéfinies, comme %{REQUEST_FILENAME} :
il fait référence au le chemin complet du système de fichiers local vers le fichier ou le script correspondant à la requête.

Ici, nous ne pouvons pas fournir une liste complète de toutes les variables disponibles, que vous pouvez trouver en visitant la documentation du mod_rewrite Apache.

Après la « chaîne de test », nous spécifions la condition qui doit être respectée : dans ce cas, nous avons utilisé !-f pour spécifier que pour l’URL de réécriture à appliquer, le fichier ou le script correspondant à la requête ne doit pas être un fichier normal existant sur le serveur (-f correspond à un fichier normal, et ! inverse le résultat).

Celle ci-dessus est un exemple très simple d’une directive RewriteCond : plus d’une peut être fournie avant la directive RewriteRule : toutes doivent correspondre pour que cette dernière soit appliquée.

Conclusions

Dans cet article, nous avons vu comment nous pouvons spécifier des redirections d’URL et des règles de réécriture d’URL dans des fichiers .htaccess lors de l’utilisation du serveur Web Apache. Nous avons vu quelques exemples très simples de l’utilisation des directives Redirect, RedirectMatch et RewriteRule et comment nous pouvons les utiliser pour obtenir des comportements spécifiques. Il s’agissait simplement d’une introduction à ces sujets, alors veuillez consulter les pages de documentation officielles pour le mod_alias et les modules mod_rewrite pour une connaissance plus approfondie.