HTTP 302 Found : ce que cela signifie

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client API, un moniteur de disponibilité ou un outil de vérification HTTP signale 302 Found.
• La réponse inclut un en-tête Location ou le client navigue visiblement vers une autre URL.
• Une requête semble fonctionner dans un navigateur, mais échoue dans un client API, car les clients gèrent différemment les redirections.
• Une requête POST ou une autre requête non-GET est redirigée et la requête de suivi ne se comporte pas comme prévu.
• Une route, un hôte, une méthode de requête, un état d’authentification ou un client est affecté, tandis que les autres URL fonctionnent normalement.
• Le DNS peut résoudre le nom et TLS peut être valide, car la requête a atteint un point de terminaison qui parle HTTP ; ces vérifications sont distinctes de la réponse de redirection.

Causes principales, classées par probabilité

1. Routage temporaire intentionnel : L’application ou le serveur web redirige les utilisateurs d’une URL vers une autre pendant une modification ou un workflow temporaire.
2. Gestion de l’authentification ou de la session : Une requête non authentifiée est redirigée vers une route de connexion ou liée à la session.
3. Logique applicative : Une route, un sélecteur de langue, un workflow de formulaire, un feature flag ou une règle dépendant de l’état de la requête renvoie une redirection pour certains utilisateurs ou certaines méthodes.
4. Configuration du reverse proxy, du CDN ou du WAF : Un intermédiaire applique une redirection avant que la requête n’atteigne l’application d’origine.
5. Cache ou configuration obsolète : Une réponse mise en cache ou une règle de routage récemment modifiée continue de produire une redirection inattendue.
6. Incompatibilité de méthode ou de sémantique de redirection : Un code 302 peut ne pas convenir lorsque la requête de suivi doit préserver la méthode et le corps de la requête d’origine ; le comportement du client doit être vérifié avant de modifier le code.

Le code d’état seul ne permet pas d’identifier le composant qui a généré la réponse ni de prouver que l’ensemble du site est défaillant.

Comment corriger le problème

Pour les visiteurs et les utilisateurs d’API

1. Réessayez une fois avec l’URL exacte et vérifiez le schéma, le nom d’hôte, le chemin, la chaîne de requête et l’orthographe.
2. Vérifiez si le client suit automatiquement les redirections. Si c’est le cas, comparez la réponse 302 d’origine avec la réponse finale au lieu de regarder uniquement la page finale.
3. Si la route nécessite une authentification, connectez-vous via le parcours habituel du site, puis réessayez. Ne saisissez pas vos identifiants sur une destination inconnue.
4. Si une requête API est affectée, notez la méthode, l’URL de la requête, le statut de la réponse, la valeur de Location et la réponse finale. Ne supposez pas qu’une redirection suivie par un navigateur constitue un comportement API valide.
5. Évitez les actualisations répétées lorsque la destination échoue ou que le service applique des limites de requêtes.
6. Si la redirection reste inattendue, envoyez au propriétaire du site l’URL, la méthode, l’horodatage, le comportement du client et les détails assainis de la réponse. Ne partagez pas de mots de passe, cookies, en-têtes d’autorisation ni secrets API.

Pour les propriétaires de sites et les développeurs

1. Reproduisez la requête exacte. Notez la méthode HTTP, l’URL complète, l’hôte, l’état d’authentification, l’user-agent, le statut, l’en-tête Location et indiquez si le client a suivi la redirection. La page finale d’un navigateur peut masquer le 302 d’origine.
2. Déterminez si la redirection est intentionnelle. Comparez la route et la méthode avec le routage, l’authentification, la gestion des langues, la maintenance et les workflows applicatifs documentés.
3. Identifiez la couche qui génère la réponse. Examinez les en-têtes de réponse et faites correspondre l’horodatage de la requête avec les journaux de l’application, du serveur web, du reverse proxy, du CDN et du WAF. Ne testez séparément un chemin vers l’origine que si votre infrastructure et vos autorisations le permettent.
4. Vérifiez la destination de la redirection. Confirmez que la valeur de Location utilise le schéma, l’hôte, le chemin et les paramètres de requête attendus. Recherchez les chaînes de redirections, les boucles, un nom d’hôte inattendu ou une destination qui renvoie une erreur.
5. Comparez les méthodes de requête. Testez séparément la méthode affectée et GET. Si la requête doit conserver sa méthode et son corps, vérifiez si la conception de l’application et le comportement du client nécessitent un code de redirection qui préserve la méthode.
6. Examinez les changements récents. Comparez les déploiements et les modifications du routage, de l’authentification, de la gestion des sessions, des règles de proxy, du comportement du CDN, des politiques du WAF et du cache.
7. Appliquez la correction sûre la plus ciblée. Modifiez uniquement la règle ou le composant responsable, avec les autorisations appropriées et un plan de restauration. Ne désactivez pas l’authentification ni les contrôles de sécurité dans le seul but de supprimer un 302.
8. Testez à nouveau la même requête. Confirmez le statut attendu, la destination, la gestion de la méthode, les en-têtes et la réponse finale. Testez ensuite les routes associées, les états authentifié et non authentifié, ainsi que les méthodes API importantes.

Prévention et vérification du correctif

• Surveillez les taux de redirection par route, méthode HTTP, hôte, statut de réponse et déploiement afin de détecter les changements inattendus de 302.
• Gérez sous contrôle de version la configuration du routage applicatif, de l’authentification, du proxy, du CDN, du WAF et du cache.
• Après chaque mise en production, testez la réponse d’origine et la destination finale des pages et points de terminaison API importants.
• Incluez les cas authentifiés, non authentifiés et les requêtes non-GET lorsque ces chemins sont pris en charge.
• Documentez les redirections temporaires intentionnelles, leurs destinations, les méthodes affectées et leur date prévue de suppression ou de réexamen.
• Conservez suffisamment longtemps des journaux serveur et applicatifs correctement assainis pour faire correspondre les incidents de redirection.
• Vérifiez les chaînes de redirections et la propriété des destinations lors des revues de configuration afin d’éviter les boucles et les changements d’hôte involontaires.

Questions fréquentes