Les redirections HTTP semblent simples en surface, mais en production elles deviennent rapidement complexes lorsque les migrations de domaines, l'application HTTPS, la compatibilité des URL legacy, le comportement SEO, la préservation de méthode et les états d'erreur convergent tous. Choisir le mauvais code de statut peut casser l'indexation des moteurs de recherche, le comportement du cache navigateur, la logique des clients API ou les flux des applications mobiles.
Dans de nombreuses organisations, les règles de redirection vivent en plusieurs endroits simultanément : code applicatif, configuration du serveur web, paramètres CDN, règles du répartiteur de charge ou scripts de maintenance ad hoc. Lorsque plusieurs systèmes définissent des redirections pour le même domaine, les boucles de redirection, les chaînes de double redirection, la perte de query string et les bugs de mauvaise cible deviennent des risques réels.
Le problème est encore plus grand dans les projets de modernisation legacy. L'ancien domaine doit rediriger vers le nouveau, l'ancienne structure de chemins s'associe à un nouveau layout d'API, certains chemins nécessitent des redirections permanentes tandis que d'autres sont temporaires. Modifier le code applicatif est lent et risqué, et l'application legacy manque souvent de la flexibilité pour le prendre en charge du tout.
La bonne approche consiste à gérer le comportement de redirection comme une règle de trafic à un point central. Le scheme, l'hôte, le chemin, la query string, le code de statut et les conditions d'erreur doivent être définis au niveau de la couche ADC afin que l'application puisse se concentrer entièrement sur la logique métier réelle.
Les Règles de Redirection HTTP de TR7 fournissent ce modèle : les transitions HTTP→HTTPS, les redirections vers une URL complète, les migrations de domaines et de chemins, et les flux de redirection déclenchés par code d'erreur sont tous gérés dans un seul modèle de politique.
TR7 transforme les redirections HTTP en règles gérables pilotées par le changement de scheme, la cible URL complète, la condition d'erreur et le contexte de trafic.
L'action `redirect_scheme` redirige le trafic HTTP vers HTTPS sans modifier le code applicatif ni la configuration du serveur web, établissant un standard de connexion sécurisée de manière centralisée.
L'action `req_redirect_location` transfère une requête vers une URL spécifique. Les domaines legacy, les anciens chemins ou les liens de campagne peuvent tous être migrés de manière centralisée vers leurs nouvelles adresses.
Une règle de redirection peut se déclencher sur un timeout ou des codes d'erreur de réponse, envoyant les utilisateurs vers une page de maintenance, de statut ou de service de secours au lieu d'une réponse d'erreur brute.
L'hôte, le chemin, la méthode, le header, l'IP source ou des expressions FX peuvent piloter la décision de redirection. Différents sous-arbres URL au sein du même vService peuvent appliquer des comportements de redirection différents.
Les Règles de Redirection HTTP consolident les scénarios de redirection — de l'application rapide de HTTPS à la redirection sur code d'erreur — sous une seule politique ADC.
La redirection HTTP vers HTTPS est une exigence de sécurité de base pour la plupart des applications. TR7 applique le changement de scheme comme règle ADC plutôt que comme code applicatif. Les requêtes arrivant via HTTP sont transmises vers la cible HTTPS ; les requêtes déjà en HTTPS ne génèrent pas de redirection parasite. Cela facilite la mise aux normes de publication sécurisée des applications legacy.
Un domaine legacy peut être transféré vers un nouveau domaine, un ancien chemin vers un nouveau chemin, ou une adresse de campagne temporaire vers une destination permanente. TR7 conserve la définition de l'URL cible complète dans la règle. Cette structure est critique dans les projets de migration, de rebranding et de modernisation applicative — le code applicatif ne doit jamais traiter les connaissances des anciennes URL.
Toutes les redirections ne portent pas la même sémantique. 301 et 308 signalent un déplacement permanent ; 302 et 307 signalent une redirection temporaire. 307 et 308 préservent la méthode de requête originale, en faisant le bon choix pour les appels API dont la méthode ne doit pas être silencieusement changée en GET. TR7 fait de la sélection du code de statut une partie explicite de la règle, ne laissant aucune ambiguïté dans le comportement de redirection.
Que la query string soit transmise vers la cible de redirection est déterminé par règle. Les liens de campagne legacy peuvent avoir besoin de transporter des paramètres de requête pour l'analyse ou le suivi. Les paramètres sensibles à la sécurité peuvent ne pas appartenir à la nouvelle cible. TR7 rend cette décision explicitement gérable à l'intérieur de la règle centrale.
Les clients API peuvent envoyer des requêtes avec les méthodes POST, PUT ou PATCH. Un mauvais code de statut de redirection peut amener le client à rétrograder silencieusement la méthode vers GET, perdant le corps de la requête. TR7 permet l'utilisation de comportements de redirection préservant la méthode tels que 307 et 308. Cela est important dans les scénarios de modernisation API et de migration d'endpoints.
Une direction canonique peut être établie entre `www.example.com` et `example.com`. Cette cohérence bénéficie au SEO, à la portée du certificat, au domaine des cookies et à l'expérience utilisateur. TR7 gère la standardisation du domaine sans distribuer la logique à la couche applicative ou au serveur web — une règle régit l'ensemble du comportement du vService.
Dans les applications legacy, des chemins tels que `/old/products/123` peuvent avoir été déplacés vers une structure différente dans la nouvelle application. Les conditions de chemin de TR7 permettent aux anciens arbres URL d'être transférés vers de nouvelles cibles. Cela empêche les signets cassés et les liens d'intégration lors d'une modernisation incrémentale, permettant une passation contrôlée vers la nouvelle application pendant que l'ancienne est encore en cours d'exécution.
Des flux similaires à `error_redirect_at_tm` redirigent les utilisateurs vers une destination alternative lorsqu'un timeout ou une erreur de gestion du trafic se produit — par exemple, une page de maintenance, une page de statut ou un domaine de secours. Au lieu d'exposer une erreur brute, une expérience contrôlée est délivrée. Les interruptions opérationnelles sont gérées avec plus de grâce.
Avec l'approche `error_redirect_at_res`, des codes d'erreur spécifiques retournés par le backend peuvent déclencher une redirection. Sur des réponses 500, 502, 503 ou 504, les utilisateurs peuvent être redirigés vers une page différente. Cela est particulièrement précieux pour les scénarios de maintenance et de dégradation de service temporaire — la gestion des erreurs devient indépendante de l'application.
L'hôte, le chemin, la méthode, le header, l'IP source ou des expressions FX peuvent être utilisés comme conditions de redirection. Par exemple, seuls les chemins mobiles, seule une version API legacy ou seul le trafic de géographies spécifiques peut être redirigé. La règle de redirection cesse d'être un comportement global aveugle et devient une décision contrôlée et sensible au contexte.
Lorsque les règles de redirection sont réparties sur plusieurs systèmes, le risque de boucle augmente. Parce que les règles TR7 vivent en un seul endroit, les conditions de scheme, d'hôte et de chemin sont plus visibles. Les opérateurs peuvent plus facilement détecter des erreurs telles que rediriger une requête déjà en HTTPS vers HTTPS ou rebondir du nouveau domaine vers l'ancien — un filet de sécurité critique pour les changements en production.
Lorsque les règles de redirection sont gérées dans le cadre du moteur de règles de trafic, l'historique des changements est traçable. Qui a redirigé quel domaine, vers quelle cible, avec quel code de statut peut être répondu via le journal d'audit. Les redirections incorrectes peuvent être annulées rapidement. Cela crée une couche de responsabilité partagée pour les équipes SEO, sécurité et opérations.
Les règles de redirection HTTP sont opérées avec la sélection du code de statut, le comportement de la query string, la préservation de méthode, les conditions d'erreur, le contrôle des boucles et les scénarios de maintenance.
301 et 308 sont utilisés pour les comportements de redirection permanente ; 302 et 307 sont utilisés pour les redirections temporaires. Lorsque la préservation de méthode est requise pour les appels API, 307 ou 308 est plus approprié. Un code de statut incorrect peut affecter le comportement du cache navigateur ou côté client, et dans le cas du 301, peut devenir difficile à annuler une fois mis en cache par les moteurs de recherche.
Les paramètres de requête doivent soit être transmis vers la cible de redirection soit y être reconstruits. Les paramètres de suivi peuvent avoir besoin d'être préservés ; les paramètres sensibles ne doivent pas être transmis. Cette décision doit être prise en fonction des exigences de sécurité et d'analyse, et doit être énoncée explicitement dans la règle plutôt que laissée aux valeurs par défaut implicites de la plateforme.
Certains codes de statut de redirection amènent le client à changer sa méthode. Pour les soumissions de formulaires ou les opérations d'écriture API, cela crée un risque de perte de données ou de traitement non intentionnel. Le code de statut approprié doit être sélectionné pour les scénarios nécessitant la préservation de méthode.
Un timeout ou un code d'erreur de réponse peut déclencher une redirection. Ces règles peuvent être utilisées pour une redirection contrôlée vers une page de maintenance ou de statut. Les redirections d'erreur ne doivent pas masquer le problème sous-jacent — elles doivent être opérées avec la journalisation et la surveillance afin que la source d'erreur réelle soit suivie séparément.
Lors de la rédaction d'une règle de redirection, l'opérateur doit vérifier que l'URL cible ne peut pas re-déclencher la même condition. Les conditions de scheme, d'hôte et de chemin doivent être clairement délimitées. La gestion centrale des règles réduit le risque de boucle en gardant toutes les conditions en un seul endroit visible.
Lors d'une maintenance planifiée, des chemins spécifiques ou un hôte entier peuvent être redirigés vers une page de maintenance temporaire. Des codes de statut temporaires tels que 302 ou 307 sont plus appropriés dans ce scénario afin que les clients ne mettent pas la redirection en cache de manière permanente. Après la maintenance, la règle est désactivée et le trafic retourne à son flux normal.
Une application legacy peut être publiée via HTTP. TR7 redirige les requêtes HTTP vers la cible HTTPS sans aucun changement au code applicatif, établissant un standard de connexion sécurisée à travers le service.
Lors d'un rebranding ou d'un changement de domaine, le trafic du domaine legacy peut être déplacé vers la nouvelle adresse. Un déplacement permanent est signalé explicitement en utilisant 301 ou 308.
Les anciens arbres URL peuvent être redirigés vers de nouveaux chemins applicatifs. Les signets des utilisateurs et les liens d'intégration legacy restent intacts tout au long de la migration.
Lorsqu'un backend est temporairement incapable de répondre, les utilisateurs peuvent être envoyés vers une page de maintenance au lieu d'une erreur brute. Une interruption opérationnelle devient une expérience utilisateur contrôlée.
Lorsque les appels POST ou PUT sont déplacés vers un nouvel endpoint API, 307 ou 308 peut être utilisé pour s'assurer que la méthode client et le comportement de requête sont préservés.
Application HTTPS, migration de domaine, redirections de chemins et redirections d'erreur — tous gérés sans aucun changement de code applicatif. Laissez-nous parcourir une mise en place en direct sur vos propres services.