HTTP 301 Moved Permanently : ce que cela signifie

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client API, un service de monitoring ou un outil de vérification HTTP signale 301 Moved Permanently.
• Un navigateur peut suivre automatiquement la redirection, afficher une URL différente ou révéler une boucle de redirection si la destination renvoie vers l’URL d’origine.
• La réponse peut contenir un en-tête Location indiquant la destination de la redirection.
• Le comportement peut se produire uniquement pour une URL, un nom d’hôte, une méthode HTTP, un état d’authentification, un user-agent ou un chemin réseau donné.
• Le DNS peut se résoudre correctement et TLS peut être négocié avec succès, puisque le point de terminaison a renvoyé une réponse HTTP.
• Selon leurs paramètres de redirection, les clients API ou les outils automatisés peuvent s’arrêter au 301 au lieu de le suivre.

Causes principales, classées par probabilité

1. Canonicalisation intentionnelle de l’URL : le site redirige un nom d’hôte, un chemin, une forme avec ou sans slash final, ou une autre variante d’URL vers l’adresse préférée.
2. Migration de protocole ou de nom d’hôte : le trafic HTTP peut être redirigé vers HTTPS, ou un ancien nom d’hôte peut pointer vers un nom d’hôte de remplacement.
3. Routage de l’application ou du framework : l’application peut rediriger une route après une modification de chemin, un changement d’état de connexion ou le déplacement d’une ressource.
4. Règles du serveur web, du reverse proxy ou du CDN : la configuration de l’infrastructure peut appliquer une redirection avant que la requête n’atteigne l’application.
5. Comportement lié à une redirection mise en cache : un navigateur, un cache intermédiaire ou un CDN peut continuer à fournir une redirection précédemment mise en cache pendant la propagation des changements de configuration.
6. Comportement propre à la méthode : une règle de redirection peut convenir à la navigation dans un navigateur, mais être inadaptée à une requête API ou à une méthode qui doit préserver la sémantique de sa requête.
7. Règles inattendues ou contradictoires : plusieurs couches peuvent rediriger vers des destinations différentes, créant une chaîne ou une boucle.

Comment corriger le problème

Si vous visitez le site

1. Vérifiez l’adresse exacte, notamment le nom d’hôte, le chemin et le protocole. Ne suivez la redirection que si la destination est familière et attendue.
2. Si la destination nécessite un compte, connectez-vous via l’interface habituelle du site et réessayez. Ne saisissez pas vos identifiants sur un domaine de redirection qui ne vous est pas familier.
3. Si le navigateur atteint la page attendue, le 301 fonctionne peut-être comme prévu. S’il boucle, aboutit au mauvais hôte ou se termine sur une page inexistante, notez l’URL d’origine et la destination.
4. Pour une API ou un client automatisé, vérifiez s’il suit les redirections et si l’URL redirigée est valide pour la même méthode de requête et le même contexte d’authentification.
5. Signalez au propriétaire du site l’URL d’origine, la destination, l’heure approximative, le type de client et le statut observé. Ne partagez pas de mots de passe, de cookies ni de secrets API.

Si vous possédez ou gérez le site

1. Reproduisez la requête exacte. Notez la méthode HTTP, l’URL complète, l’hôte, le protocole, l’état d’authentification le cas échéant, le statut final et chaque destination de redirection.
2. Examinez les en-têtes de réponse, en particulier Location, les en-têtes liés au cache, ceux liés à l’authentification et tout en-tête identifiant un proxy ou une couche serveur.
3. Déterminez quel composant a produit le 301 : application, serveur web, reverse proxy, CDN ou WAF. Consultez les journaux correspondants à partir de l’horodatage de la requête et d’un identifiant de requête s’il est disponible.
4. Comparez le comportement avec la conception de routage prévue. Confirmez si la redirection doit gérer un changement de nom d’hôte, une règle HTTP vers HTTPS, un chemin canonique, une ressource déplacée ou un flux applicatif.
5. Recherchez les chaînes de redirection, les boucles, les règles contradictoires et une destination incorrecte. Examinez les déploiements récents et les changements apportés au routage, à l’authentification, au cache, au proxy ou à la configuration du CDN.
6. Appliquez la correction autorisée la plus ciblée au niveau qui a généré la réponse. Évitez les modifications générales des permissions, de la sécurité ou des règles de redirection lorsqu’une seule route ou condition est incorrecte.
7. Testez à nouveau la même URL et la même méthode depuis un client adapté. Testez ensuite la destination, les routes associées importantes et les cas authentifiés et non authentifiés pertinents.
8. Si vous soupçonnez une redirection mise en cache, suivez le processus approuvé d’invalidation du cache du site et évaluez son impact opérationnel avant d’effectuer cette modification.

Prévention et vérification du correctif

• Définissez et documentez les redirections intentionnelles, notamment les anciennes URL, les destinations, les méthodes concernées et les responsables.
• Placez sous gestion de versions les règles du serveur web, de l’application, du reverse proxy, du CDN et du WAF lorsque cela est possible.
• Après chaque mise en production, testez les URL canoniques, le comportement HTTP vers HTTPS, les changements de nom d’hôte, les méthodes API importantes et les routes authentifiées.
• Surveillez les taux de redirection, les chaînes et les boucles par route et par déploiement, plutôt que de considérer chaque 301 comme une panne.
• Conservez les journaux des requêtes et de l’infrastructure suffisamment longtemps pour établir la correspondance avec les redirections inattendues.
• Examinez le comportement du cache lorsque vous modifiez les règles de redirection afin que des réponses obsolètes ne masquent pas le résultat de la correction.

Questions fréquentes