Réponse HTTP GET

Obtenir les headers et le body d'une requête HTTP GET

Réponse HTTP GET : vérifier le statut, les headers et le contenu d’une URL

Lorsqu’un navigateur ouvre une page web, il ne se contente pas d’afficher une adresse. Il envoie une requête HTTP à un serveur, qui lui retourne une réponse contenant notamment un code de statut, des en-têtes HTTP et, selon le cas, un corps de réponse.

Comprendre cette communication est essentiel pour les développeurs web, les administrateurs système, les intégrateurs API et toute personne qui souhaite diagnostiquer le fonctionnement d’un site ou d’une ressource accessible sur Internet.

L’outil Réponse HTTP GET de PleaseTools permet d’effectuer simplement une requête HTTP GET vers une URL et d'examiner la réponse retournée par le serveur.

Il suffit d’entrer une URL, puis de lancer la requête pour obtenir les informations disponibles sur la réponse HTTP.

Qu’est-ce qu’une requête HTTP GET ?

HTTP, pour Hypertext Transfer Protocol, est le protocole utilisé pour les échanges entre les clients et les serveurs sur le Web.

Un client peut être :

  • un navigateur ;
  • une application mobile ;
  • un script ;
  • un serveur ;
  • un robot ;
  • un outil de développement ;
  • une autre application.

Lorsqu’un client souhaite récupérer une ressource, il peut utiliser la méthode HTTP GET.

Par exemple :

GET /index.html HTTP/1.1
Host: exemple.com

Le serveur traite cette requête et retourne une réponse.

La méthode GET est destinée à demander une représentation d’une ressource. Elle est considérée comme une méthode sûre et idempotente dans les sémantiques HTTP, et elle est notamment utilisée pour récupérer des pages, des données ou des fichiers.

Qu’est-ce qu’une réponse HTTP ?

Une réponse HTTP est le message envoyé par le serveur après réception d’une requête.

Elle contient généralement trois informations importantes :

  1. un code de statut HTTP ;
  2. des en-têtes HTTP (headers) ;
  3. un corps de réponse (body).

Par exemple, une réponse HTTP peut ressembler à :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234

<!doctype html>
<html>
...
</html>

Le serveur indique donc à la fois le résultat de la requête et les informations associées à la ressource retournée.


À quoi sert l’outil Réponse HTTP GET ?

L’outil Réponse HTTP GET de PleaseTools permet d’interroger une URL et d’examiner sa réponse HTTP.

La page de l’outil propose simplement :

  • un champ URL ;
  • un exemple d’adresse ;
  • un bouton Valider.

Après l'exécution de la requête, l’objectif est de consulter les informations retournées par le serveur, notamment :

  • le statut HTTP ;
  • les headers ;
  • le body de la réponse.

Cela peut être particulièrement pratique lorsqu’on souhaite rapidement vérifier le comportement d’une URL sans ouvrir les outils de développement du navigateur ou écrire une commande curl.

Comment utiliser Réponse HTTP GET sur PleaseTools ?

L’utilisation est très simple.

Étape 1 : entrer l’URL

Dans le champ Entrer l’URL, saisissez l’adresse de la ressource que vous souhaitez tester.

Par exemple :

https://example.com

Vous pouvez également tester une URL correspondant à :

  • une page HTML ;
  • un fichier ;
  • une ressource publique ;
  • un endpoint d’API ;
  • une URL avec des paramètres ;
  • une ressource retournant une erreur HTTP.

Étape 2 : lancer la requête

Cliquez sur Valider.

PleaseTools effectue alors une requête HTTP GET vers l’adresse indiquée.

Étape 3 : analyser la réponse

La réponse peut être examinée à travers plusieurs éléments.

Le premier est le statut HTTP.

Viennent ensuite les en-têtes HTTP, puis le corps de la réponse lorsque celui-ci est disponible.


Comprendre les codes de statut HTTP

Le code de statut est l’une des informations les plus importantes d’une réponse HTTP.

Il permet de savoir comment le serveur a traité la requête.

Les codes sont regroupés en cinq grandes familles.

Famille Signification
1xx Information
2xx Succès
3xx Redirection
4xx Erreur côté client
5xx Erreur côté serveur

Code 200 : OK

Le statut :

200 OK

indique généralement que la requête a abouti avec succès.

Par exemple, lorsqu’une page HTML est correctement récupérée :

HTTP/1.1 200 OK

C’est l’un des statuts les plus courants lors de la récupération d’une ressource Web.

Code 201 : Created

Le code 201 Created indique qu’une ressource a été créée.

Il est particulièrement fréquent dans certaines API après une opération de création.

Il est cependant moins typique d’une simple requête GET, puisque GET est principalement utilisé pour récupérer des représentations de ressources.

Code 204 : No Content

Le code :

204 No Content

indique que la requête a réussi mais que la réponse ne contient pas de contenu à retourner.

Cela explique pourquoi une requête peut être considérée comme réussie tout en ayant un body vide.

Code 301 : Moved Permanently

Le statut 301 indique une redirection permanente.

Par exemple :

http://example.com

peut rediriger vers :

https://example.com

Le serveur peut utiliser l’en-tête Location pour indiquer la destination.

Code 302 : Found

302 Found correspond à une redirection temporaire dans de nombreux scénarios.

Lorsqu’un outil de diagnostic rencontre ce code, il est intéressant d’examiner les headers afin d’identifier la destination de la redirection.

Code 304 : Not Modified

Le statut 304 Not Modified est utilisé dans les mécanismes de cache HTTP.

Il indique notamment qu’une représentation en cache peut encore être utilisée lorsque les conditions de la requête le permettent.

Code 400 : Bad Request

Le serveur considère que la requête reçue est incorrecte.

Cela peut être lié à :

  • une URL mal formée ;
  • des paramètres invalides ;
  • des données de requête incorrectes ;
  • une syntaxe HTTP non valide.

Code 401 : Unauthorized

Ce statut indique qu’une authentification est nécessaire ou qu’elle n’a pas été correctement fournie.

Il peut apparaître lorsqu’une URL nécessite une authentification.

Code 403 : Forbidden

Le serveur a compris la requête mais refuse l’accès à la ressource.

Un 403 peut être lié à des règles d'accès, à une authentification insuffisante, à des protections anti-bot ou à d'autres mécanismes de sécurité.

Code 404 : Not Found

Le célèbre :

404 Not Found

indique généralement que la ressource demandée n'a pas été trouvée.

Par exemple :

https://example.com/page-inexistante

peut retourner :

HTTP/1.1 404 Not Found

La page actuelle de PleaseTools cite justement 200 et 404 comme exemples de codes de statut permettant d’identifier le résultat d’une requête.

Code 500 : Internal Server Error

Le statut 500 indique généralement un problème interne du côté du serveur.

Il peut être provoqué par :

  • une exception dans l’application ;
  • une erreur de configuration ;
  • une dépendance défaillante ;
  • un problème de serveur ;
  • une erreur d’exécution.

Un 500 ne signifie donc pas nécessairement que l’URL est inexistante.


Les headers HTTP : pourquoi sont-ils importants ?

Les headers HTTP transportent des informations supplémentaires sur la requête ou la réponse.

Exemple :

Content-Type: text/html; charset=UTF-8

indique le type de contenu retourné.

D’autres headers peuvent indiquer :

  • la politique de cache ;
  • la date de la réponse ;
  • la taille du contenu ;
  • les cookies ;
  • les mécanismes de compression ;
  • la politique de sécurité ;
  • la provenance d'une ressource ;
  • les informations relatives à certaines redirections.

Les en-têtes constituent donc une source d'information très utile pour diagnostiquer une réponse HTTP.

Content-Type

Le header :

Content-Type: text/html

indique que le serveur retourne du HTML.

Une API peut plutôt retourner :

Content-Type: application/json

Un fichier CSS peut utiliser :

Content-Type: text/css

et une image JPEG :

Content-Type: image/jpeg

Ce header permet donc de comprendre la nature du contenu retourné.

Content-Length

Content-Length peut indiquer la taille du contenu de la réponse lorsqu’il est présent.

Par exemple :

Content-Length: 24576

Cela peut être utile pour comprendre la quantité de données retournée.

Cache-Control

Le header :

Cache-Control

permet notamment de définir des directives relatives à la mise en cache.

Il est particulièrement important pour les performances des sites et applications Web.

Location

Lorsqu’une réponse effectue une redirection, le header :

Location

peut indiquer l’URL vers laquelle le client doit se diriger.

Par exemple :

Location: https://example.com/nouvelle-page

Set-Cookie

Un serveur peut utiliser :

Set-Cookie

pour demander au client de stocker un cookie.

Il faut cependant faire attention lorsque l’on teste des services authentifiés ou contenant des données sensibles.


Qu’est-ce que le body HTTP ?

Le body est le contenu transporté par la réponse lorsque celle-ci en possède un.

Dans le cas d'une page Web, il peut contenir du HTML :

<!doctype html>
<html>
    <head>
        <title>Exemple</title>
    </head>
    <body>
        <h1>Hello</h1>
    </body>
</html>

Une API peut retourner du JSON :

{
    "status": "success",
    "message": "Hello"
}

Une ressource peut également retourner du texte, du XML ou d'autres types de contenu.

HTTP est utilisé pour transporter bien plus que des pages HTML : il peut notamment servir à récupérer des images, vidéos et autres ressources.


GET et paramètres dans l’URL

Une requête GET peut contenir des paramètres dans l’URL.

Par exemple :

https://example.com/search?q=laravel

Ici :

q=laravel

fait partie de la chaîne de requête (query string).

On peut avoir plusieurs paramètres :

https://example.com/search?q=laravel&page=2

Les paramètres sont séparés par &.

La syntaxe générale est :

https://example.com/ressource?parametre=valeur

La méthode GET utilise donc fréquemment l’URL elle-même pour transmettre les paramètres nécessaires à la récupération d’une ressource.


GET versus POST

Il est important de ne pas confondre les méthodes GET et POST.

GET

GET est principalement destiné à récupérer une représentation d’une ressource.

GET /users/25 HTTP/1.1

POST

POST est généralement utilisé pour transmettre des données au serveur, notamment lors de la création ou de la soumission de données.

POST /users HTTP/1.1

Une différence importante est que les données d’une requête GET sont fréquemment placées dans la query string, tandis que POST peut transmettre un contenu dans le corps de la requête.

La documentation HTTP distingue explicitement les sémantiques de GET et POST.


GET ne doit pas être utilisé pour n’importe quelle action

Le fait qu’une URL soit accessible avec GET ne signifie pas qu’il est approprié d’utiliser GET pour provoquer une modification importante sur un serveur.

Une requête GET est définie comme une méthode sûre : elle est destinée à récupérer une représentation plutôt qu'à provoquer une modification demandée par le client.

C'est notamment une raison pour laquelle les actions destructrices ou les modifications importantes ne devraient pas être déclenchées simplement par l’ouverture d’une URL GET.


Pourquoi tester une URL avec une requête HTTP GET ?

L’outil peut être utile dans de nombreuses situations.

Vérifier qu'une URL répond

Vous pouvez rapidement vérifier si une ressource retourne une réponse HTTP et quel est son statut.

Par exemple :

https://example.com

Diagnostiquer une erreur 404

Lorsqu'une page semble inaccessible, une requête GET peut aider à confirmer que le serveur retourne effectivement :

404 Not Found

Identifier une redirection

Une URL peut ne plus être directement accessible mais rediriger vers une autre adresse.

Les headers permettent alors notamment d'examiner les informations associées à cette redirection.

Examiner le Content-Type

Une URL censée retourner du JSON peut être vérifiée afin de déterminer quel type de contenu le serveur annonce.

Vérifier une API publique

Une API qui expose une route GET peut être interrogée afin d'observer sa réponse.

Par exemple :

https://api.example.com/users

La réponse peut être du JSON :

[
    {
        "id": 1,
        "name": "John"
    }
]

Déboguer une application Web

Lors du développement, les headers et le statut HTTP peuvent fournir des informations importantes sur le comportement du serveur.


Réponse HTTP GET et API REST

Les API Web utilisent très fréquemment HTTP.

Une API peut par exemple proposer :

GET    /users
GET    /users/15
POST   /users
PUT    /users/15
PATCH  /users/15
DELETE /users/15

Dans ce contexte, une requête GET permet généralement de récupérer :

GET /users

ou :

GET /users/15

L’outil Réponse HTTP GET est donc particulièrement intéressant pour tester rapidement les endpoints accessibles avec GET.

Il faut toutefois noter qu’un endpoint nécessitant une authentification ou des headers spécifiques peut ne pas produire la même réponse qu’une requête envoyée par votre application.


Exemple avec curl

Les développeurs peuvent également effectuer une requête GET depuis un terminal avec curl.

curl https://example.com

Pour afficher également les informations de réponse :

curl -i https://example.com

Vous pouvez alors obtenir quelque chose comme :

HTTP/1.1 200 OK
Content-Type: text/html

<!doctype html>
<html>
...
</html>

L'avantage de curl est qu'il permet une automatisation très poussée.

L'avantage d'un outil Web comme PleaseTools est de pouvoir effectuer rapidement un test ponctuel sans préparer une commande.


Exemple avec JavaScript Fetch

En JavaScript, une requête GET peut être réalisée avec l'API fetch() :

fetch('https://example.com')
    .then(response => {
        console.log(response.status);
        return response.text();
    })
    .then(body => {
        console.log(body);
    });

Pour une API JSON :

fetch('https://api.example.com/users')
    .then(response => {
        console.log(response.status);
        return response.json();
    })
    .then(data => {
        console.log(data);
    });

Le navigateur fournit alors au développeur un objet Response contenant notamment le statut et les headers de la réponse.


Exemple avec PHP

En PHP, une application peut également effectuer une requête HTTP.

Avec Laravel, par exemple :

use Illuminate\Support\Facades\Http;

$response = Http::get('https://example.com');

$status = $response->status();
$body = $response->body();

Pour une API JSON :

$response = Http::get('https://api.example.com/users');

$data = $response->json();

L’analyse des réponses HTTP est donc directement liée au développement d’applications Web modernes.


Pourquoi un navigateur peut-il donner un résultat différent ?

Un point important lors du diagnostic HTTP est que toutes les requêtes ne sont pas identiques.

Un navigateur peut envoyer différents headers et informations supplémentaires.

Par exemple :

User-Agent
Accept
Accept-Language
Cookie
Referer

Un serveur peut utiliser ces informations pour adapter sa réponse.

Il peut également appliquer :

  • une authentification ;
  • une protection anti-bot ;
  • une limitation de débit ;
  • une restriction géographique ;
  • une politique de sécurité ;
  • une vérification de session.

Par conséquent, une requête GET effectuée par un outil externe peut parfois obtenir une réponse différente de celle obtenue dans votre navigateur.


Pourquoi une URL peut-elle fonctionner dans le navigateur mais pas avec un outil ?

Plusieurs raisons sont possibles.

Authentification

La page peut nécessiter une session ou un cookie.

Protection anti-bot

Le serveur peut détecter certaines requêtes automatisées.

Headers obligatoires

Une API peut exiger certains headers.

User-Agent

Certains serveurs adaptent leur réponse selon le client.

Redirection

Le navigateur peut suivre automatiquement une chaîne de redirections.

Restrictions réseau

Le serveur peut autoriser certaines adresses IP ou certains réseaux.

TLS ou certificat

Un problème de certificat ou de négociation TLS peut empêcher certains clients d'établir correctement la connexion.

Il faut donc interpréter le résultat d'un test HTTP dans son contexte.


GET, DNS et serveur : trois problèmes différents

Lorsqu'une URL ne fonctionne pas, il faut distinguer plusieurs niveaux.

Supposons :

https://example.com

Avant même d'obtenir une réponse HTTP, le client doit notamment résoudre le nom de domaine.

On peut donc avoir :

Domaine
   ↓
DNS
   ↓
Adresse IP
   ↓
Connexion réseau
   ↓
TLS/HTTPS
   ↓
Requête HTTP
   ↓
Réponse HTTP

Une erreur DNS n'est donc pas la même chose qu'une erreur HTTP 404 ou 500.

C'est pourquoi l'outil Réponse HTTP GET est particulièrement complémentaire d'autres outils réseau de PleaseTools.


Réponse HTTP GET, DNS Records et Whois

Ces outils ne répondent pas à la même question.

Outil Question principale
Réponse HTTP GET Que retourne cette URL ?
DNS Records Quels enregistrements DNS possède ce domaine ?
Whois Quelles informations sont associées au domaine ?
Localisation IP Où se situe approximativement cette adresse IP ?
Mon IP publique Quelle est mon adresse IP publique ?
IP Converter Comment représenter cette adresse IP ?

Une analyse complète peut donc utiliser plusieurs outils.

Par exemple :

Domaine
   ↓
DNS Records
   ↓
Adresse IP
   ↓
Réponse HTTP GET
   ↓
Statut + Headers + Body

Les erreurs HTTP les plus utiles à connaître

Voici quelques statuts particulièrement utiles lors du diagnostic :

Code Signification Exemple de situation
200 OK Ressource récupérée
201 Created Ressource créée
204 No Content Succès sans contenu
301 Redirection permanente Ancienne URL
302 Redirection Redirection temporaire
304 Not Modified Cache
400 Bad Request Requête incorrecte
401 Unauthorized Authentification requise
403 Forbidden Accès refusé
404 Not Found Ressource inexistante
405 Method Not Allowed Méthode HTTP non autorisée
429 Too Many Requests Limitation de requêtes
500 Internal Server Error Erreur serveur
502 Bad Gateway Problème entre serveurs
503 Service Unavailable Service indisponible
504 Gateway Timeout Délai d'attente dépassé

Connaître ces codes permet de passer rapidement du simple constat d'échec à une première hypothèse de diagnostic.


À quoi servent les headers dans le référencement ?

Les réponses HTTP jouent également un rôle dans l'analyse technique d'un site Web.

Les redirections, les erreurs 404, les réponses 200, les règles de cache et d'autres informations HTTP peuvent avoir des conséquences sur le fonctionnement d'un site et sur la manière dont les robots accèdent à ses ressources.

Pour un développeur ou un spécialiste SEO technique, vérifier la réponse HTTP d'une URL constitue donc une opération simple mais utile.

Il ne faut cependant pas réduire le SEO au seul code HTTP : le contenu, les liens, les directives d'indexation, les performances et de nombreux autres facteurs interviennent également.


Bonnes pratiques pour tester une URL

Lorsque vous analysez une URL, voici une méthode simple.

1. Vérifiez le statut

Commencez par regarder le code HTTP.

200
404
301
500
...

2. Regardez les redirections

Si le serveur retourne une redirection, identifiez la destination et vérifiez si le comportement est attendu.

3. Analysez Content-Type

Vérifiez que le type de contenu correspond à ce que vous attendiez.

Une API JSON qui retourne :

text/html

peut signaler une situation à investiguer.

4. Examinez les headers utiles

Portez notamment attention aux headers liés à :

  • cache ;
  • contenu ;
  • redirection ;
  • cookies ;
  • sécurité.

5. Analysez le body

Lorsque la réponse possède un corps, regardez ce que le serveur retourne réellement.

Cela peut immédiatement révéler :

  • une page d'erreur ;
  • une réponse JSON ;
  • une page HTML ;
  • un message d'authentification ;
  • une redirection ;
  • une ressource inattendue.

Quand utiliser Réponse HTTP GET de PleaseTools ?

L'outil est particulièrement pratique lorsque vous souhaitez obtenir rapidement une réponse HTTP sans mettre en place un environnement de développement.

Il peut être utilisé pour :

  • tester une URL ;
  • vérifier un code HTTP ;
  • examiner des headers ;
  • visualiser le body d'une réponse ;
  • tester une URL d'API GET ;
  • diagnostiquer une erreur 404 ;
  • identifier une redirection ;
  • vérifier le type de contenu retourné ;
  • effectuer un contrôle rapide avant de poursuivre une investigation.

Pour une analyse ponctuelle, il constitue donc un petit outil de diagnostic réseau directement accessible depuis le navigateur.


FAQ sur les requêtes HTTP GET

Qu'est-ce qu'une requête HTTP GET ?

Une requête HTTP GET demande au serveur une représentation d'une ressource. Elle est principalement utilisée pour récupérer des données ou des ressources.

Qu'est-ce qu'une réponse HTTP GET ?

C'est la réponse retournée par le serveur après une requête GET. Elle peut notamment contenir un code de statut, des headers et un body.

À quoi sert le code HTTP 200 ?

200 OK indique généralement que la requête a été traitée avec succès.

Que signifie 404 ?

404 Not Found indique généralement que la ressource demandée n'a pas été trouvée.

Que signifie 500 ?

500 Internal Server Error indique généralement une erreur interne du serveur.

Quelle est la différence entre GET et POST ?

GET est principalement utilisé pour récupérer une ressource, tandis que POST est généralement utilisé pour transmettre des données au serveur et peut entraîner une modification de son état.

Peut-on utiliser GET pour tester une API ?

Oui. De nombreuses API proposent des endpoints GET permettant de récupérer des ressources ou des données.

Une requête GET peut-elle avoir des paramètres ?

Oui. Les paramètres peuvent notamment être transmis dans la query string de l'URL :

https://example.com/search?q=php

Pourquoi une URL retourne-t-elle 301 ou 302 ?

Le serveur indique généralement qu'une redirection est nécessaire. Les headers de la réponse peuvent fournir des informations supplémentaires sur cette redirection.

Pourquoi une URL fonctionne-t-elle dans mon navigateur mais pas avec un outil HTTP ?

Le navigateur peut envoyer des cookies, headers, informations d'authentification ou autres éléments qui ne sont pas présents dans une requête HTTP simple.

Est-ce qu'une erreur HTTP signifie que le serveur est complètement inaccessible ?

Non. Une réponse 404, 403 ou 500 signifie justement que le serveur a pu répondre avec un statut HTTP. Une absence totale de réponse peut correspondre à un problème différent, par exemple DNS, réseau, TLS ou délai d'attente.

Conclusion

Une requête HTTP GET est l'une des opérations fondamentales du Web. Elle permet notamment de demander à un serveur une représentation d'une ressource, qu'il s'agisse d'une page HTML, d'une réponse JSON, d'une image ou d'un autre contenu.

Pour diagnostiquer une URL, il ne suffit toutefois pas de savoir si elle « fonctionne ». Il est souvent beaucoup plus intéressant d'examiner précisément :

  • le code de statut HTTP ;
  • les headers ;
  • le Content-Type ;
  • les éventuelles redirections ;
  • le body de la réponse.

Réponse HTTP GET de PleaseTools permet justement d'effectuer cette vérification simplement : entrez une URL, lancez la requête et examinez la réponse retournée par le serveur.

C'est un outil particulièrement pratique pour les développeurs, intégrateurs, administrateurs système, créateurs de sites et utilisateurs d'API qui souhaitent effectuer rapidement un diagnostic HTTP sans passer immédiatement par curl, un script PHP ou les outils de développement du navigateur.