Inspecteur d'en-têtes HTTP — ce que le fil a réellement retourné, pas ce que le navigateur a rendu

Le navigateur est le pire endroit pour vérifier ce qu’un point d’accès HTTP retourne réellement. Il suit silencieusement les redirections, cache les réponses, garde une session TLS précédente, et laisse un service worker réécrire la réponse avant que vous ne la voyiez. Quand un déploiement a l’air bizarre et que vous devez confirmer ce que le serveur a envoyé, vous voulez un outil qui récupère l’URL à neuf, suit chaque saut, et vous montre les en-têtes de réponse bruts sans rien rendre. C’est à cela que sert l’Inspecteur d’en-têtes HTTP de PortJar.

Ce que fait l’outil

L’inspecteur envoie une requête GET depuis un serveur PortJar, suit chaque redirection 3xx jusqu’au bout, et retourne les en-têtes, la ligne de statut et le chronométrage pour chaque saut. La réponse finale est annotée avec les en-têtes de sécurité trouvés — HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — et ceux qui manquent. Le corps n’est pas rendu ; le but est de voir exactement ce que le fil a livré, dans l’ordre où il l’a livré.

Parce que la récupération provient de PortJar plutôt que de votre navigateur, il n’y a ni pot à témoins partagé, ni session TLS partagée, ni extension altérant la réponse. La réponse est ce qu’un client frais aurait vu à la première requête. C’est la réponse que vous voulez quand quelqu’un dit « mais ça marche chez moi ».

Comment l’utiliser

Ouvrez portjar.com/tools/http-headers, collez l’URL complète avec le schéma, et lancez. Le résultat affiche chaque saut de la chaîne — l’URL demandée, le code de statut, les en-têtes de réponse — suivi de la réponse finale avec le résumé des en-têtes de sécurité. Envoyez l’URL à un collègue et il verra exactement la même chaîne quand il la chargera.

Quand vous y recourriez

Vérifier qu’un déploiement a réellement été livré. Après une mise en production, récupérer l’entrée et lire ETag, Last-Modified, ou un en-tête X-Build-Id personnalisé est le moyen le plus rapide de confirmer que le nouvel artéfact est servi. Une valeur périmée signifie un cache CDN, un travailleur bloqué, ou un backend mal routé.
Confirmer que HSTS est correctement réglé avant la soumission à la liste de préchargement. Une directive includeSubDomains ou preload manquante est invisible dans un navigateur jusqu’à ce que la soumission échoue. L’inspecteur vous montre la valeur exacte de l’en-tête Strict-Transport-Security d’un seul coup.
Déboguer un rapport « le site charge mais les ressources sont bloquées ». Lisez l’en-tête Content-Security-Policy sur la réponse du document. Neuf fois sur dix, la CSP a été resserrée par un changement récent et un script de fournisseur ne correspond plus à une source autorisée.
Reproduire un bogue de redirection qu’un client n’arrive pas à montrer en partage d’écran. La liste des sauts de l’inspecteur montre si une redirection est 301 ou 302, si elle dépouille les témoins, et si elle change le schéma. Les devtools du navigateur masquent la plupart de cela une fois la chaîne résolue.
Confirmer qu’un domaine personnalisé ou une URL de fournisseur atterrit bien sur votre origine. Récupérer le domaine personnalisé à travers l’inspecteur expose chaque saut — y compris ceux que le fournisseur ajoute pour le suivi.

Quoi faire de la sortie

Lisez la chaîne de haut en bas. Le code de statut de chaque saut vous dit si la redirection est permanente (301, 308) ou temporaire (302, 303, 307) — cette distinction compte pour le référencement et pour la façon dont les caches en aval traitent la réponse. Une chaîne de plus de deux sauts sur un point d’accès en production mérite un second regard ; les chaînes de redirection cumulent la latence et gaspillent le budget de requêtes.

Regardez les Content-Type, Cache-Control et Set-Cookie de la réponse finale. Un document servi en text/plain au lieu de text/html est presque toujours une origine mal configurée ou une cartographie MIME manquante. Un Cache-Control: no-store sur une page que le CDN devrait cacher signifie que le CDN ne fait rien pour vous. Un Set-Cookie sans Secure ni HttpOnly est un constat à consigner.

Le résumé des en-têtes de sécurité en bas est une liste de triage rapide. HSTS manquant sur un site en production est presque toujours fautif. CSP manquant est courant mais mérite un signalement. X-Content-Type-Options: nosniff manquant est trivial à corriger et vaut la peine d’être fait. Combinez le verdict avec le guide PortJar sur le port 443 ouvert mais le site qui ne charge pas quand les en-têtes n’expliquent pas une défaillance côté utilisateur.

Si la chaîne se termine sur un 5xx, les en-têtes eux-mêmes sont diagnostiques — regardez les valeurs Server, Via, et tout X-Request-Id pour déterminer quelle couche a répondu.

Pour les environnements où la politique d’en-têtes, l’hygiène des redirections et le comportement du CDN doivent rester cohérents sur plusieurs sites, Stack Harbor s’en occupe dans le cadre des environnements infogérés.