Rédigé par Rédaction CyberSDF / 17 septembre 2026

Comprendre HTTP : requêtes, réponses et codes de statut

En bref : HTTP décrit l’échange entre un client, souvent un navigateur, et un serveur. Pour comprendre ce qui se passe, lisez la méthode et la cible de la requête, puis le code de statut et les en-têtes de la réponse. curl permet d’observer cet échange sans interface graphique.

HTTP n’est pas le contenu d’une page. C’est le protocole qui organise la demande d’une ressource et la réponse du serveur. Le navigateur envoie une requête, le serveur renvoie une réponse, puis le navigateur interprète la représentation reçue. La RFC 9110 sur les sémantiques HTTP décrit les règles communes aux clients, serveurs et intermédiaires.

Une requête indique ce que le client demande

Une requête commence par une méthode, une cible et une version de protocole. Elle peut ensuite contenir des en-têtes, puis un corps quand l’opération transmet des données.

GET /documentation HTTP/1.1
Host: example.com
Accept: text/html

GET demande une représentation de la ressource. /documentation est la cible dans cet exemple. Host indique le nom du serveur visé et Accept exprime le type de contenu que le client sait recevoir. La ligne HTTP/1.1 décrit la syntaxe de l’échange, pas la version de la page demandée.

Les méthodes courantes ont un rôle distinct. GET lit, POST transmet une nouvelle donnée ou demande une action, PUT remplace une représentation, PATCH la modifie partiellement et DELETE demande sa suppression. Le serveur peut refuser une méthode qui n’est pas prévue pour la ressource.

Le corps de requête porte les données envoyées

Un formulaire peut envoyer ses champs dans le corps d’une requête POST. Les en-têtes disent comment interpréter ces octets.

POST /contact HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

name=Camille&format=html

Content-Type décrit le format du corps. Avec du JSON, l’en-tête devient généralement application/json et le corps suit cette syntaxe. Une donnée sensible ne doit pas être copiée dans un terminal partagé ni dans une commande conservée par l’historique du shell.

La réponse donne d’abord un statut

En HTTP/1.1, la première ligne d’une réponse indique la version et un nombre à trois chiffres ; elle peut aussi comporter une courte raison lisible. HTTP/2 et HTTP/3 conservent les mêmes sémantiques de statut, mais transmettent leurs messages dans une autre syntaxe que cette ligne textuelle.

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

Le nombre est le code de statut. Il résume le résultat de la requête. Les en-têtes qui suivent précisent le type, la taille, la mise en cache, une nouvelle adresse ou les conditions d’accès. Le corps contient ensuite la représentation, par exemple du HTML ou du JSON.

2xx : le serveur a traité la demande

3xx : le client doit tenir compte d’une autre représentation

301 Moved Permanently et 308 Permanent Redirect indiquent un changement durable d’adresse. 302 Found et 307 Temporary Redirect décrivent un déplacement temporaire. Pour les variantes 307 et 308, la méthode et le corps doivent être conservés lors du suivi ; cette précision compte pour un POST. 304 Not Modified ne fournit pas de corps : le client peut réutiliser une représentation conservée si ses conditions de cache le permettent.

4xx : la requête ne peut pas être satisfaite telle quelle

5xx : le traitement a échoué côté serveur

500 Internal Server Error désigne une erreur générale du serveur. 502 Bad Gateway signifie qu’un serveur agissant comme passerelle a reçu une réponse invalide d’un service en amont. 503 Service Unavailable indique une indisponibilité temporaire ou une surcharge ; l’en-tête Retry-After peut préciser quand réessayer. 504 Gateway Timeout signifie que la passerelle n’a pas reçu à temps la réponse du service en amont.

Les en-têtes expliquent le traitement

Un code seul ne raconte pas tout l’échange. Ces en-têtes reviennent souvent :

• Content-Type indique le type de représentation, avec son encodage éventuel.
• Location donne une autre adresse, notamment pour une redirection ou une ressource créée.
• Cache-Control, ETag et Last-Modified participent au contrôle du cache.
• Allow liste les méthodes acceptées quand le serveur répond 405.
• Retry-After donne un délai ou une date de nouvelle tentative pour certains refus temporaires.

Le corps doit être lu avec le type annoncé. Une réponse JSON ne se traite pas comme une page HTML, même si les deux arrivent dans une réponse HTTP réussie.

Observer l’échange avec curl

Le manuel officiel de curl documente les options utilisées ci-dessous. La commande suivante demande une page en HTTP/1.1, ne conserve pas son corps dans un fichier et imprime quelques mesures utiles :

curl -sS --http1.1 --max-time 30 \
  -o /dev/null \
  -w 'status=%{http_code} http_version=%{http_version} content_type=%{content_type} bytes=%{size_download} time_total=%{time_total}\n' \
  https://example.com/

Mesure exécutée le 17 septembre 2026 sur https://example.com/ :

status=200 http_version=1.1 content_type=text/html bytes=559 time_total=0.083967

Le nombre 200 vient de %{http_code}, 1.1 de %{http_version}, text/html de %{content_type}, et 559 de %{size_download}. La durée 0.083967 est exprimée en secondes par %{time_total}. Elle dépend du moment, du réseau et du serveur.

Pour voir les en-têtes et le corps ensemble, utilisez -i. Pour demander seulement les en-têtes avec la méthode HEAD, utilisez -I. Pour suivre une redirection et afficher l’adresse finale, ajoutez -L. Ces options ne répondent pas à la même question : -I ne vérifie pas le téléchargement du corps et -L masque le premier statut si vous ne regardez pas toute la sortie.

Passer du symptôme au contrôle

Un diagnostic commence par le statut qui revient, puis vérifie les éléments adaptés :

• 404 : recopiez l’URL exacte, contrôlez le chemin sensible à la casse et vérifiez que la route existe sur le serveur visé.
• 401 ou 403 : distinguez l’absence d’authentification d’un droit insuffisant, puis examinez les règles d’accès.
• 405 : l’adresse est peut-être correcte, mais la méthode ne l’est pas ; l’en-tête Allow donne un indice.
• 429 : ralentissez les appels et respectez le délai indiqué avant de recommencer.
• 502, 503 ou 504 : la chaîne entre le serveur visible et son service amont est à examiner ; le client ne peut pas corriger seul cette panne.

Pour les commandes de terminal, la page consacrée au terminal Linux rappelle les bases utiles. Si le problème touche la connexion de la machine plutôt que la réponse d’un serveur web, utilisez le diagnostic réseau sous Linux. Pour comparer un programme à installer selon vos contraintes, consultez la grille de choix d’un logiciel.

Le statut décrit l’échange, pas le métier

Un code HTTP confirme le résultat de la communication entre le client et le serveur ; il ne dit pas si une action métier a produit la valeur attendue. Pour l’interpréter correctement, associez toujours le statut aux en-têtes, au type de contenu et au corps réellement reçus.

La syntaxe complète de HTTP/1.1 est détaillée dans la RFC 9112. Elle devient utile quand vous devez lire les lignes, les délimitations du corps ou les échanges entre intermédiaires.