Une petite boîte à outils pour déboguer les redirections et les en-têtes HTTP en production

Le problème du débogage HTTP en production

La plupart des problèmes HTTP sont invisibles dans le navigateur. Une chaîne de redirection échoue silencieusement, un en-tête de cache comporte une erreur d’un seul caractère, une politique CORS bloque une requête sans explication. Les outils de développement du navigateur vous montrent le résultat de l’échange, mais ils masquent souvent l’échange brut qui a causé le problème.

C’est particulièrement important en production, où vous ne pouvez pas ajouter de journalisation ni redémarrer des services pour voir ce qui a changé. Vous avez besoin d’outils qui montrent l’échange HTTP réel : en-têtes de requête, en-têtes de réponse, codes d’état, cibles de redirection, minutage. Voici les cinq outils qui font ce travail de manière fiable, ainsi que les techniques de navigateur qui les complètent.

curl : la base

curl est le premier outil à utiliser, parce qu’il vous montre exactement ce que le serveur a envoyé, sans interprétation du navigateur entre les deux.

Pour voir les en-têtes de réponse sans le corps :

curl -I https://example.com

Pour suivre les redirections et voir chaque étape :

curl -L -v https://example.com

L’option -v (verbose) affiche la requête et la réponse complètes, y compris tous les en-têtes. L’option -L suit automatiquement les redirections. Ensemble, elles vous montrent toute la chaîne de redirection, là où se trouvent la plupart des problèmes de production.

Pour voir uniquement les destinations de redirection :

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

C’est utile lorsque vous devez vérifier une chaîne de redirection sans le bruit des en-têtes complets. L’option -w formate la sortie pour n’afficher que le code d’état et l’URL suivante dans la chaîne.

curl vous permet aussi d’envoyer des en-têtes personnalisés, ce qui est essentiel pour tester le comportement d’un CDN, l’authentification ou des points de terminaison d’API :

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie : curl avec de meilleurs réglages par défaut

httpie est un outil Python qui fait ce que fait curl, mais avec une syntaxe plus facile à mémoriser et une sortie plus facile à lire. Ce n’est pas un remplacement — curl est plus puissant et plus largement installé — mais pour des vérifications rapides, httpie est plus rapide.

Pour voir les en-têtes :

http HEAD https://example.com

Pour suivre les redirections :

http --follow --all https://example.com

L’option --all affiche chaque réponse dans la chaîne de redirection, pas seulement la dernière. C’est l’équivalent de curl -L -v, mais la sortie est colorée et plus facile à parcourir.

Pour envoyer du JSON :

http POST https://api.example.com name=value

httpie suppose JSON par défaut, ce qui évite de taper davantage lorsque vous testez des API. Il formate aussi joliment la réponse, ce qui facilite le repérage d’en-têtes mal formés ou de valeurs inattendues.

Browser DevTools : onglet Network

L’onglet Network du navigateur est l’endroit par lequel commencer si le problème ne se produit que dans le navigateur. Il vous montre les mêmes informations que curl, mais il vous montre aussi l’interprétation du navigateur : s’il a bloqué une requête, comment il a géré la mise en cache, s’il a envoyé des cookies.

Pour voir les en-têtes complets de requête et de réponse, cliquez sur n’importe quelle requête dans l’onglet Network, puis regardez la section Headers. La vue « Raw » montre les en-têtes exactement tels qu’ils ont été envoyés, sans mise en forme.

Pour voir les chaînes de redirection, cherchez les requêtes avec des codes d’état 3xx. Le navigateur les regroupe sous la requête finale, mais vous pouvez les développer pour voir chaque étape. C’est là que vous trouverez les boucles de redirection, les en-têtes Location manquants ou les redirections qui pointent vers le mauvais domaine.

Pour voir le minutage, regardez l’onglet Timing pour n’importe quelle requête. Il vous montre combien de temps le navigateur a passé sur la résolution DNS, la connexion TCP, la négociation TLS et l’attente du serveur. Si une redirection est lente, l’onglet de minutage vous indique si le problème vient de la latence réseau ou du traitement côté serveur.

Une limite : le navigateur masque certains en-têtes pour des raisons de sécurité. Les en-têtes Set-Cookie sont visibles, mais les valeurs réelles des cookies sont caviardées. Les en-têtes Authorization sont parfois entièrement masqués. Si vous devez les voir, utilisez curl.

mitmproxy : le proxy d’interception

mitmproxy est un outil Python qui se place entre votre navigateur et le serveur, et vous montre chaque requête et chaque réponse en temps réel. Il est plus complexe que curl, mais c’est le seul outil qui vous montre ce que le navigateur envoie réellement, y compris les en-têtes que le navigateur ajoute automatiquement.

Pour le démarrer :

mitmproxy

Configurez ensuite votre navigateur pour utiliser localhost:8080 comme proxy HTTP. mitmproxy vous montrera chaque requête dans une interface de terminal. Vous pouvez inspecter les en-têtes, modifier les requêtes avant leur envoi ou rejouer des requêtes avec des paramètres différents.

C’est utile pour déboguer les problèmes qui ne se produisent que dans le navigateur : requêtes de pré-vérification CORS, gestion des cookies ou requêtes qui échouent lorsque certains en-têtes sont présents. C’est également utile pour tester le comportement de votre site derrière un proxy d’entreprise ou un VPN, parce que mitmproxy peut simuler ces environnements.

L’inconvénient est la complexité de configuration. Vous devez installer un certificat racine pour que mitmproxy puisse intercepter le trafic HTTPS, et vous devez configurer votre navigateur pour utiliser le proxy. Pour des vérifications rapides, curl est plus rapide. Pour un débogage approfondi, mitmproxy vaut le temps de configuration.

webpagetest : la perspective de la production

WebPageTest est un service gratuit qui charge votre page depuis de vrais navigateurs dans différents emplacements et vous montre l’échange HTTP complet. Il est plus lent que curl, mais il vous montre ce que vivent de vrais utilisateurs, y compris le comportement du CDN, la résolution DNS et la négociation TLS.

Les vues « Request Headers » et « Response Headers » vous montrent exactement ce que le navigateur a envoyé et reçu. La vue « Waterfall » vous montre le minutage de chaque requête, y compris les redirections. C’est là que vous trouverez les problèmes qui ne se produisent que dans certaines régions ou sur certains réseaux.

WebPageTest vous montre aussi la chaîne de redirection du document principal, là où se trouvent la plupart des problèmes de redirection. Si votre site redirige de http:// vers https://, puis de www. vers non-www., puis de / vers /en/, WebPageTest vous montre les trois étapes et le temps que chacune a pris.

Pour des outils qui vous aident à valider et à optimiser ces fondamentaux HTTP, Wux Webtools propose plusieurs utilitaires qui s’exécutent entièrement dans votre navigateur, notamment des analyseurs d’en-têtes et des vérificateurs de redirections qui respectent votre vie privée en traitant tout côté client.

Quand les en-têtes mentent

Les problèmes HTTP les plus difficiles sont ceux où le serveur envoie des en-têtes contradictoires. Un en-tête Cache-Control indique no-cache, mais un en-tête Expires indique que la ressource est valide pendant un an. Un en-tête Location pointe vers une URL relative, mais l’en-tête Content-Location pointe ailleurs. Le navigateur doit deviner lequel croire, et différents navigateurs devinent différemment.

Lorsque cela arrive, vous devez voir les en-têtes bruts dans l’ordre où le serveur les a envoyés. curl -v le fait. mitmproxy aussi. Les DevTools du navigateur réordonnent parfois les en-têtes pour améliorer la lisibilité, ce qui masque le problème.

Autre problème courant : des en-têtes ajoutés par un CDN ou un répartiteur de charge, et non par votre application. Si vous déboguez un problème de mise en cache, vous devez savoir si l’en-tête Cache-Control vient de votre application ou du CDN. curl vous montre le résultat final, mais ne vous dit pas d’où vient chaque en-tête. Pour cela, vous devez contourner le CDN (en atteignant directement le serveur d’origine) et comparer les en-têtes.

Le problème de la boucle de redirection

Les boucles de redirection sont le problème HTTP le plus courant en production. Elles se produisent lorsque deux serveurs ne sont pas d’accord sur la destination d’une URL : le CDN redirige vers l’origine, l’origine redirige vers le CDN. Ou le répartiteur de charge redirige HTTP vers HTTPS, mais l’application redirige HTTPS vers HTTP parce qu’elle ne voit pas l’en-tête X-Forwarded-Proto.

Pour déboguer cela, vous devez voir toute la chaîne de redirection, y compris l’en-tête Location à chaque étape. curl -L -v le fait, mais il s’arrête après 50 redirections pour éviter les boucles infinies. Si vous atteignez cette limite, vous avez une boucle de redirection.

La correction est généralement un changement de configuration : dire à l’application de faire confiance à l’en-tête X-Forwarded-Proto, ou dire au CDN d’arrêter de rediriger les requêtes qui sont déjà en HTTPS. Mais vous ne pouvez pas corriger le problème tant que vous ne voyez pas la boucle, et le navigateur ne vous montrera pas plus que quelques redirections avant d’abandonner.

Ce qu’il faut vérifier en premier

Quand quelque chose casse en production, vérifiez ces points dans l’ordre :

1. Code d’état : est-ce celui que vous attendiez ? Un 301 est permanent, un 302 est temporaire, un 307 conserve la méthode HTTP. Si vous voyez le mauvais code, le problème se trouve dans votre configuration de redirection.

1. En-tête Location : pointe-t-il vers le bon endroit ? Est-ce une URL absolue ou relative ? Les URL relatives sont résolues par rapport à l’URL actuelle, ce qui peut produire des résultats inattendus si l’URL de base n’est pas celle que vous pensez.

1. En-têtes de cache : le navigateur met-il la redirection en cache ? Une redirection 301 est mise en cache par défaut, ce qui signifie qu’une redirection mal configurée peut casser votre site pendant des heures même après correction. Vérifiez les en-têtes Cache-Control et Expires pour voir combien de temps le navigateur se souviendra de la redirection.

1. En-têtes CORS : si la requête est cross-origin, le serveur envoie-t-il le bon en-tête Access-Control-Allow-Origin ? Sinon, le navigateur bloquera la requête, et vous verrez une erreur CORS dans la console. Les en-têtes de réponse du serveur sont le seul endroit où corriger cela — vous ne pouvez pas le contourner dans le navigateur.

1. Minutage : combien de temps la requête a-t-elle pris ? Si elle est lente, est-ce de la latence réseau ou du traitement côté serveur ? Les DevTools du navigateur et WebPageTest affichent tous deux des ventilations de minutage qui vous indiquent où le temps est passé.

Pour approfondir l’évolution du comportement des navigateurs autour de la confidentialité et des en-têtes, consultez ce qui a changé pour les cookies en 2026 et quoi faire à ce sujet, qui couvre les implications des récentes mises à jour des navigateurs sur les en-têtes et le consentement.

Points clés

• curl -L -v vous montre toute la chaîne de redirection et tous les en-têtes, sans interprétation du navigateur
• L’onglet Network du navigateur vous montre ce que le navigateur a fait de la réponse, y compris les décisions de mise en cache et de CORS
• mitmproxy vous montre ce que le navigateur a envoyé, y compris les en-têtes que le navigateur ajoute automatiquement
• WebPageTest vous montre ce que vivent de vrais utilisateurs, y compris le comportement du CDN et les différences régionales
• Les boucles de redirection et les en-têtes contradictoires sont les problèmes de production les plus courants, et ils sont invisibles sans inspection HTTP brute

FAQ

Q : Pourquoi curl affiche-t-il des en-têtes différents de ceux du navigateur ?

R : Parce que le navigateur ajoute automatiquement des en-têtes (User-Agent, Accept, Cookie) et suit ses propres règles de mise en cache et de CORS. curl n’envoie que ce que vous lui demandez d’envoyer. Pour voir ce que le navigateur envoie réellement, utilisez mitmproxy ou les DevTools du navigateur.

Q : Comment déboguer une redirection qui ne se produit que pour certains utilisateurs ?

R : Vérifiez si la redirection dépend des en-têtes envoyés par l’utilisateur : User-Agent, Accept-Language, Cookie ou adresse IP (via X-Forwarded-For). Utilisez curl pour envoyer les mêmes en-têtes que l’utilisateur, ou utilisez WebPageTest pour charger la page depuis l’emplacement de l’utilisateur.

Q : Quelle est la différence entre les redirections 301 et 302 ?

R : Un 301 est permanent et indique au navigateur de mettre la redirection en cache (parfois pour toujours). Un 302 est temporaire et indique au navigateur de ne pas la mettre en cache. Si vous ne savez pas lequel utiliser, utilisez 302 — vous pourrez toujours le changer en 301 plus tard.

Q : Pourquoi ma redirection fonctionne-t-elle dans curl, mais pas dans le navigateur ?

R : Probablement parce que le navigateur met en cache une ancienne redirection, ou parce qu’il bloque la redirection à cause des règles CORS ou de contenu mixte. Vérifiez la console des DevTools du navigateur pour les erreurs, et vérifiez les en-têtes Cache-Control pour voir si le navigateur utilise une réponse mise en cache.

Q : Comment voir les en-têtes ajoutés par un CDN ?

R : Utilisez curl pour atteindre l’URL du CDN, puis utilisez de nouveau curl pour atteindre directement le serveur d’origine (en contournant le CDN). Comparez les en-têtes. Ceux qui n’apparaissent que dans la première réponse viennent du CDN.

<!-- tool-cta:start -->

💡 Essayez ceci : Lorsque vous traquez des problèmes de redirection, Redirect Checker retrace toute la chaîne et affiche les codes d’état et les en-têtes à chaque saut.

<!-- tool-cta:end -->

Sources

• curl documentation — Référence officielle des options en ligne de commande et du comportement de curl
• HTTPie documentation — Guide de la syntaxe et des fonctionnalités de httpie
• MDN Web Docs: HTTP redirections — Explication complète des codes d’état et du comportement des redirections HTTP
• WebPageTest documentation — Comment interpréter les résultats et les en-têtes WebPageTest