redirection.io : recettes de règles

Cette page de documentation liste plusieurs cas d'usage et des façons de les réaliser en créant des règles redirection.io. Nous vous conseillons également de parcourir les "recettes", qui peuvent être une bonne source d'exemples pour résoudre des problèmes avancés avec redirection.io

Créer une redirection HTTP vers HTTPS

Nous prenons entièrement en charge les redirections HTTP vers HTTPS, que ce soit sur le même domaine ou d'un domaine à un autre.

• dans le champ "URL source" du trigger, saisissez l'URL HTTP absolue accompagnée d'un marqueur de type anything ;
• dans le champ "URL cible" de l'action, saisissez l'URL HTTPS absolue et utilisez le marqueur précédemment créé.

redirection.io prend en charge de nombreux types de marqueurs, pas seulement le type anything. Dans tous les exemples fournis sur cette page, vous pouvez utiliser le type de marqueur le mieux adapté à votre cas d'utilisation.

Rediriger d'un (sous-)domaine vers un autre

Lors du déploiement d'un site web, il est recommandé de choisir d'utiliser le domaine racine ou le sous-domaine www. En effet, publier votre site web sur example.com et www.example.com pourrait créer du contenu dupliqué, ce qui est évidemment quelque chose que vous n'aimeriez pas.

La création d'une redirection (sous-domaine) peut être réalisée en quelques étapes :

• dans le champ "URL source" du trigger, saisissez l'URL absolue sans le schéma accompagnée d'un marqueur de type anything. L'utilisation d'une URL sans schéma appliquera les redirections aux deux protocoles HTTP et HTTPS ;
• dans le champ "URL cible" de l'action, saisissez l'URL de destination HTTPS absolue et utilisez le marqueur précédemment créé. Bien sûr, le domaine de destination peut être celui de votre choix, soit le domaine racine, un autre sous-domaine ou un domaine complètement différent.

Rediriger plusieurs (sous-)domaines vers un autre

Dans certains cas, vous voudrez rediriger plusieurs (sous-)domaines vers un autre. Bonne nouvelle, dans redirection.io, les marqueurs fonctionnent aussi dans la partie "domaine" des URL et peuvent être combinés !

Rediriger plusieurs domaines

Si vous voulez rediriger plusieurs domaines, saisissez une URL de la forme ://[DOMAINS]/[ANYTHING] dans le champ "URL source" du trigger, où :

• [DOMAINS] est un marqueur qui correspond à tous les domaines que vous voulez rediriger. Il peut être un marqueur de type anything, si vous voulez rediriger tous les domaines associés et "proxyfiés" par ce projet redirection.io, ou un autre type de marqueur (par exemple, un marqueur de type enum si les domaines à rediriger sont une liste finie) ;
• [ANYTHING] est un marqueur de type anything

Rediriger plusieurs sous-domaines d'un domaine donné

Si vous voulez rediriger tous les sous-domaines d'un domaine donné, saisissez une URL de la forme ://[SUBDOMAINS].example.com/[ANYTHING] dans le champ "URL source" du trigger, où :

• [SUBDOMAINS] est un marqueur qui correspond à tous les sous-domaines que vous voulez rediriger. Il peut être un marqueur de type anything, si vous voulez rediriger tous les sous-domaines, ou un autre type de marqueur (par exemple, un marqueur de type enum si les sous-domaines à rediriger sont une liste finie) ;
• [ANYTHING] est un marqueur de type anything

Rediriger les URL uniquement lorsque le backend génère une 404

Imaginez que votre site web affiche une liste de pages produits éphémères sous le chemin /products. Ces produits sont en quantité limitée et, lorsqu'ils sont en rupture de stock, la page telle qu'elle a été développée dans l'application backend disparaît.

Dans cette configuration, qui est assez fréquente, les produits en rupture de stock généreront une erreur 404, ce qui est dommage pour plusieurs raisons :

• la page a dû être indexée par les moteurs de recherche, donc les utilisateurs tomberont sur une erreur en visitant cette page, ce qui n'est pas positif pour l'image de votre marque ou votre entreprise ;
• vous perdez la possibilité de faire découvrir vos autres produits aux utilisateurs.

L'automatisation de l'exécution des redirections dans ce contexte peut être réalisée en ajoutant le trigger code de statut de réponse du backend en plus du trigger URL source. En quelques étapes :

• dans le champ "URL source" du trigger, saisissez le modèle d'URL pour lequel les redirections doivent être exécutées (utilisez donc un marqueur de type anything pour faire correspondre un groupe de pages).
• ajoutez une exigence de déclenchement STATUT DU BACKEND, et restreignez cette règle pour qu'elle ne soit déclenchée que lorsqu'une erreur 404 est sur le point de se produire

Les triggers de règles peuvent être combinés pour restreindre les conditions qui déclencheront l'exécution d'une règle. Si vous avez un cas d'utilisation spécifique qui ne semble pas être pris en charge par nos triggers actuellement disponibles, veuillez nous contacter pour nous faire part de vos besoins !

Bloquer un User-Agent ou une adresse IP spécifique

Même si ce n'est pas le cas d'utilisation principal pour redirection.io, le système de règles peut être utilisé pour empêcher l'accès à votre site web sous certaines conditions.

Bien que vous puissiez créer ce type de règle à la main, nous vous recommandons de consulter les « recettes redirection.io » pour vous aider à bloquer les requêtes illégitimes. Par exemple, la recette « Bloquer les bots IA » bloque les crawlers dédiés à l'entraînement des IA.

Par exemple, imaginez que vous vouliez renvoyer une erreur 404 pour toutes les requêtes effectuées avec le User-Agent bad-bot/1.0. Vous pourriez créer une règle qui combine le trigger "URL source" et le trigger "En-tête de requête" :

• dans le champ "URL source" du trigger, utilisez un marqueur de type anything (pour que cette règle soit appliquée à toutes les URL) ;
• ajoutez un trigger "En-tête de requête", choisissez le nom d'en-tête User-Agent, et définissez la valeur que vous voulez bloquer ;
• ajoutez l'action "404" pour que le module redirection.io renvoie une réponse 404 pour toutes ces requêtes.

La même approche s'applique pour bloquer une méthode HTTP spécifique, une adresse IP ou une plage d'adresses IP, etc. En savoir plus sur les triggers dans notre documentation

Ignorer tous les paramètres de requête dans une règle donnée

Il peut arriver que, pour une raison ou une autre, vous ayez besoin d'ignorer tous les paramètres de chaîne de requête, et d'effectuer une redirection, que ces paramètres soient définis ou non.

Par exemple, considérez que vous voulez rediriger toutes les requêtes effectuées vers des URL de la forme /some-path?[OPTIONAL_QUERY_STRING]. Cela inclut les chemins sans aucune chaîne de requête (/some-path), et aussi les URL avec une chaîne de requête (/some-path?true, /some-path?test=1, etc.)

Gérer les paramètres de chaîne de requête est tout à fait possible dans les règles redirection.io :

• dans le champ "URL source" du trigger, saisissez le modèle d'URL pour lequel les redirections doivent être exécutées. Pour notre exemple, utilisez /some-path[ANYTHING] (où [ANYTHING] est un marqueur de type anything).
• dans l'URL cible de l'action "rediriger", écrivez l'URL vers laquelle les requêtes doivent être redirigées. Vous pouvez choisir de réinjecter les paramètres de requête, ou de les ignorer complètement.

Il y a un cas délicat : si l'URL source elle-même se termine par un marqueur. Par exemple, disons que vous voulez rediriger toutes les pages d'une catégorie spécifique vers les mêmes pages dans un autre dossier, quelle que soit la chaîne de requête.

Dans ce cas, vous créeriez la règle comme d'habitude, avec un marqueur pour faire correspondre les pages que vous voulez rediriger, et vous ajouteriez un marqueur de type regex à la fin, avec (\?.+)? comme valeur de l'expression régulière, pour faire correspondre également les requêtes qui arrivent avec une chaîne de requête.

S'il existe de nombreux cas de ce type dans votre ensemble de règles, vous pourriez vouloir transformer le marqueur queryString ci-dessus en un modèle de marqueur, afin d'éviter de vous répéter !

Ignorer le slash final dans les URL

Il existe un débat de longue date sur la question de savoir si une URL se terminant par un slash doit servir le même contenu que l'URL sans le slash final, et nous recevons souvent des questions de clients qui souhaitent que leur redirection fonctionne à la fois pour une URL se terminant par un / et pour la même URL sans le symbole slash final.

Les standards et les RFC sont clairs : de telles URL ne sont pas équivalentes et représentent des ressources différentes. C'est pourquoi redirection.io traite ces cas comme des URL distinctes. Si vous créez une règle dont l'"URL source" s'applique à /some-path/, elle ne sera pas déclenchée lorsqu'une requête arrive sur /some-path (et vice versa).

La vie réelle, cependant, ne correspond pas toujours parfaitement aux standards. Pour certains de nos clients, ignorer un slash final dans le processus de correspondance des URL est une nécessité, car leur site web a une longue histoire d'ignorance de ces slashes finaux. Dans certains cas, la situation est encore plus compliquée, car les slashes finaux doivent être ignorés pour certaines URL du site web, mais sont importants à différencier sur d'autres URL.

Heureusement, redirection.io peut vous aider dans un tel cas !

1. Allez dans l'onglet "paramètres" > "fonctionnalités" de votre projet, et faites défiler jusqu'à la section "Modèles de marqueurs"
2. Dans la section "modèles de marqueurs", créez un nouveau modèle de marqueur. Appelez-le "trailingslash", et utilisez [TRAILING_SLASH] comme "marqueur CSV". Si vous importez un fichier CSV contenant exactement cette chaîne, elle sera remplacée par une instance de ce modèle de marqueur.
3. Choisissez le type "regex", et utilisez l'expression régulière suivante : /?
4. Une fois le modèle de marqueur défini, il peut être utilisé dans le formulaire de création de règle

Si vous souhaitez ignorer tous les slashes finaux (pas seulement un /, mais aussi plusieurs slashes finaux comme ///, par exemple, modifiez l'expression régulière pour utiliser /*. Lors de la création de la règle, joignez plusieurs exemples à la règle, afin de vérifier qu'elle fonctionne comme prévu à l'étape "impact" :

Redirections et cache

Dans certaines configurations d'environnement d'hébergement, redirection.io peut ne pas être le premier logiciel sur le chemin d'une requête HTTP. Bien que de telles configurations d'infrastructure fonctionnent parfaitement, elles peuvent parfois être la cause de comportements étranges.

Par exemple, si un proxy inverse de mise en cache gère les réponses de votre plateforme Web (y compris les réponses de redirection générées par redirection.io), vous vous demandez peut-être pourquoi la désactivation d'une règle de redirection ne produit aucun effet. Il existe plusieurs façons d'analyser et d'éviter de tels pièges :

• utilisez la fonction "Tester les règles", dans le menu de gauche du gestionnaire : saisissez l'URL à vérifier et vous saurez quelles règles redirection.io sont exécutées pour cette requête. Si aucune règle n'est appliquée, mais que cette URL continue de générer une redirection, cela peut être le signe que la redirection a été mise en cache, soit dans un proxy inverse de mise en cache comme Varnish, soit directement dans votre navigateur ;
• lisez les en-têtes de réponse : lorsqu'un proxy de mise en cache est actif, il ajoute souvent des en-têtes supplémentaires comme x-cache, via, etc. Une réponse x-cache contenant la valeur HIT, par exemple, indique que la réponse est servie directement par un proxy inverse de mise en cache ;
• vous pouvez empêcher les réponses de redirection.io d'être mises en cache par un proxy inverse en ajoutant un en-tête de réponse Cache-control: no-cache à l'aide de redirection.io lui-même. Bien sûr, gardez à l'esprit que cela empêchera les réponses d'être mises en cache, utilisez donc cette fonctionnalité avec précaution !
• rappelez-vous également que les redirections 301 sont par défaut mises en cache par les navigateurs, sans aucune date d'expiration ! Bien sûr, une redirection "permanente" est censée être... permanente, mais vos exigences commerciales peuvent évoluer, et une redirection que vous pensiez permanente pourrait devoir être annulée par la suite. Pour atténuer cela :
  • veillez à toujours utiliser le bon code de redirection. Si vous n'êtes pas absolument sûr qu'une redirection doit être permanente, pour toujours, utilisez plutôt un code de statut de redirection temporaire (302 ou 307)
  • alternativement, vous pouvez définir un en-tête Cache-Control pour toutes les réponses de redirection renvoyées par redirection.io (voir ci-dessous).

Comment empêcher les redirections d'être mises en cache

Empêcher les réponses de redirection d'être mises en cache peut être fait en utilisant le trigger de code de statut de réponse du backend, ainsi que l'action d'en-tête de réponse :

• créez un trigger avec /<ANYTHING> comme URL source, et ajoutez une restriction sur le code de statut de réponse pour cibler uniquement les réponses 3xx ;
• ajoutez une action en-tête de réponse, avec la valeur cache-control: no-cache (ou toute autre valeur pertinente, voir MDN pour la référence complète)

Une fois qu'une telle règle est enregistrée et publiée, toutes les réponses de redirection ultérieures passant par redirection.io seront accompagnées d'un en-tête de réponse cache-control: no-cache, demandant aux proxys inverses et aux navigateurs de ne pas mettre en cache de telles réponses.