Recherche des en-têtes HTTP

La Recherche des en-têtes HTTP est un outil gratuit qui récupère tous les en-têtes de réponse HTTP renvoyés par une URL lors d'une requête GET classique.

Que sont les en-têtes de réponse HTTP ?

Les en-têtes de réponse HTTP sont des métadonnées envoyées par un serveur web avant le corps de la réponse, par exemple une page HTML, une image ou un document JSON. Ils indiquent au client comment interpréter, mettre en cache, rediriger ou sécuriser la réponse.

Une réponse HTTP/1.x commence normalement par une ligne d'état HTTP, suivie des en-têtes. Avec HTTP/2 et HTTP/3, l'état équivalent est transmis dans le pseudo-en-tête :status. D'un point de vue technique, la ligne d'état HTTP/1.x est distincte des en-têtes, mais elle est souvent affichée avec eux, car elle indique si la requête a abouti. Un état 200 signifie que la ressource a été renvoyée, 301 ou 302 signale une redirection, 404 indique que la ressource est introuvable et 500 correspond à une erreur côté serveur.

Les en-têtes peuvent provenir du serveur d'origine, d'un proxy inverse ou d'un réseau de diffusion de contenu tel que Cloudflare. Certains sont ajoutés ou supprimés à mesure que la réponse traverse ces systèmes. Le résultat peut donc décrire d'autres éléments que l'application ayant généré la page.

Comment rechercher les en-têtes HTTP d'une URL ?

Saisis l'URL complète à vérifier, avec son schéma, par exemple https://www.example.com/account. L'outil envoie une requête GET classique depuis son serveur, puis affiche les en-têtes HTTP reçus de cette URL.

Pour comparer précisément les en-têtes de réponse, utilise les variantes exactes des URL à examiner. Les en-têtes de http://example.com, https://example.com et https://www.example.com peuvent différer, car chaque adresse peut avoir ses propres redirections, règles de mise en cache et paramètres de serveur.

La syntaxe de l'URL influe également sur la requête :

• Les espaces ne sont pas valides tels quels dans une URL. Ils doivent normalement être encodés avec un code de pourcentage, le plus souvent %20 dans un chemin.
• ? marque le début de la chaîne de requête. & et = sont couramment utilisés dans les chaînes encodées comme des formulaires, mais ils n'ont pas nécessairement ce rôle dans toutes les chaînes de requête.
• Les noms de domaine accentués ou utilisant des caractères non latins sont traités avec IDNA et représentés sous forme d'étiquettes A en ASCII, commençant généralement par xn--. Les caractères du chemin sont, quant à eux, généralement convertis en octets UTF-8, puis encodés avec des codes de pourcentage.
• Un fragment commençant par # est traité par le navigateur et n'est pas envoyé dans la requête HTTP.
• Il n'existe aucune longueur maximale universelle pour une URL. Une URL très longue peut être refusée par un serveur, un proxy ou une application.

Comment interpréter les en-têtes HTTP obtenus ?

Examine les en-têtes en rapport avec le problème que tu cherches à résoudre. Les noms d'en-têtes ne sont pas sensibles à la casse, mais la syntaxe de leurs valeurs peut l'être.

D'autres en-têtes peuvent être propres à l'application. Par exemple, Access-Control-Allow-Origin détermine quelles origines peuvent lire une réponse au moyen de requêtes interorigines dans le navigateur. Un en-tête Server peut désigner un logiciel ou un proxy, mais il ne constitue pas une preuve fiable de la plateforme sous-jacente, car les administrateurs peuvent le modifier ou le supprimer.

Exemples pratiques de diagnostic

Les problèmes de redirection sont une raison courante d'examiner les en-têtes. Imaginons que https://example.com/old-page renvoie l'état 301 avec Location: https://example.com/new-page. Le serveur demande alors au client d'accéder à la nouvelle adresse. En vérifiant successivement chaque destination, tu peux repérer une boucle de redirection ou un basculement inattendu entre HTTP et HTTPS.

Si une page obsolète est servie par Cloudflare ou un autre CDN, examine Cache-Control, Age, ETag ainsi que tout en-tête de cache propre au fournisseur. Une valeur Age élevée indique l'âge calculé de la réponse en cache, avec éventuellement le temps passé dans des caches en amont, et non la durée pendant laquelle un intermédiaire précis l'a conservée. Elle ne prouve pas que tous les caches régionaux contiennent la même version.

Lorsqu'une API fonctionne dans un script côté serveur, mais échoue dans un navigateur, examine Content-Type et les en-têtes de réponse CORS, notamment Access-Control-Allow-Origin. Si un point de terminaison JSON renvoie text/html, il fournit peut-être en réalité une page d'erreur ou un écran de connexion. En l'absence d'autorisation interorigine, le navigateur peut bloquer l'accès même si le serveur a renvoyé l'état 200.

Les en-têtes peuvent aussi aider à diagnostiquer un site qui semble indisponible. Une réponse 503 suggère une panne temporaire du serveur ou d'un service en amont, tandis qu'un état 404 signifie que le chemin demandé est introuvable. Ils ne permettent toutefois pas d'identifier toutes les pannes. Si la résolution DNS, la connexion TCP ou la négociation TLS échoue avant qu'une réponse HTTP existe, il peut n'y avoir aucun en-tête de réponse à examiner. Ping permet de tester séparément la connectivité, tandis que le Vérificateur HTTP/2 peut contrôler la prise en charge du protocole.

Pourquoi un résultat correct peut-il sembler erroné ?

Un résultat correct peut différer de celui de ton navigateur, car les caches, les enregistrements DNS et le contexte de la requête peuvent orienter les deux requêtes vers des réponses différentes. Cette recherche est effectuée côté serveur. Elle peut donc atteindre un autre noeud du CDN ou résoudre un enregistrement DNS récemment modifié plus tôt ou plus tard que ton réseau local.

Les navigateurs envoient aussi leurs propres cookies, types de contenu acceptés, langues et validateurs de cache. Une page WordPress consultée après connexion peut donc renvoyer des règles de cache différentes de celles obtenues par une requête anonyme envoyée depuis un serveur. Le routage géographique et les systèmes de gestion des robots peuvent également faire varier la réponse selon le réseau d'origine ou les en-têtes de la requête.

Après une modification du DNS, les résolveurs dotés d'un cache peuvent continuer à utiliser l'ancien enregistrement jusqu'à l'expiration de sa durée de vie. Lorsque le trafic atteint le nouveau serveur, un ancien objet du CDN ou le cache du navigateur peut encore renvoyer le contenu précédent. Vérifie séparément l'hôte résolu, purge les caches si nécessaire et compare l'URL exacte au lieu de supposer que tous les noms d'hôte partagent la même configuration.

Questions fréquentes

Est-ce que l'outil affiche les en-têtes de la requête ?

Non. Il récupère les en-têtes de réponse renvoyés par l'URL lors d'une requête GET classique. Les en-têtes de requête sont les métadonnées envoyées au serveur. Pour les examiner dans leur intégralité, il faut utiliser séparément les outils de développement du navigateur, les journaux du serveur ou un client en ligne de commande.

Les URL saisies dans l'outil restent-elles confidentielles ?

La recherche est effectuée sur le serveur. Ta saisie est transmise à ce serveur via HTTPS et n'est pas stockée. Évite de saisir des URL contenant des mots de passe, des jetons d'accès ou des paramètres de requête sensibles, car le serveur de destination recevra lui aussi ces valeurs lors de la requête.

Les en-têtes HTTP peuvent-ils expliquer un avertissement de certificat ?

En général, ils ne suffisent pas à eux seuls. La connexion TLS est établie avant l'envoi de la réponse HTTP. Un certificat expiré, un nom d'hôte qui ne correspond pas ou une autorité émettrice non approuvée peut donc empêcher le renvoi de tout en-tête. Si l'avertissement du navigateur apparaît avant le chargement de la page, examine séparément le certificat et sa chaîne de certification.

Pourquoi plusieurs en-têtes Set-Cookie sont-ils renvoyés ?

Une réponse peut définir plusieurs cookies, chacun utilisant son propre champ Set-Cookie. Ne les regroupe pas comme s'il s'agissait d'une liste séparée par des virgules, car les dates d'expiration des cookies peuvent elles-mêmes contenir des virgules. Vérifie séparément le domaine, le chemin et les attributs de sécurité de chaque cookie.

Est-ce que je peux comparer le résultat avec curl ?

Oui. Une commande telle que curl -D - https://example.com/ -o /dev/null affiche les en-têtes de réponse tout en ignorant le corps. La version de curl, les en-têtes de requête, les paramètres de redirection et l'emplacement réseau peuvent produire un résultat différent. Fais donc correspondre ces conditions avant de conclure qu'une différence provient d'un problème de serveur.