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.
Sommaire
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/htmlGET 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=htmlContent-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: 1842Le 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
| Code | Signification pratique | À regarder ensuite |
|---|---|---|
| 200 OK | La demande a abouti et une représentation peut être fournie. | Le type indiqué par Content-Type et le contenu reçu. |
| 201 Created | Une ressource a été créée. | L’en-tête Location quand le serveur donne sa nouvelle adresse. |
| 204 No Content | La demande a abouti sans contenu à renvoyer. | Les en-têtes, car il n’y a pas de document à afficher. |
| 206 Partial Content | Une partie de la représentation est renvoyée. | Content-Range et la demande de plage. |
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
| Code | Ce qu’il signale | Premier contrôle |
|---|---|---|
| 400 Bad Request | La syntaxe ou les données de la requête sont invalides. | La cible, les paramètres et le format envoyé. |
| 401 Unauthorized | Une authentification est nécessaire ou invalide. | Le mécanisme d’authentification demandé par le serveur. |
| 403 Forbidden | Le serveur refuse l’accès à la ressource. | Les droits et la règle d’accès, pas seulement l’identifiant. |
| 404 Not Found | Le serveur ne trouve pas la ressource correspondant à la cible demandée. | L’URL exacte, le chemin et le routage du serveur. |
| 405 Method Not Allowed | La ressource existe mais la méthode n’est pas acceptée. | L’en-tête Allow et la méthode attendue. |
| 429 Too Many Requests | Le client a envoyé trop de requêtes dans une période donnée, selon la définition de la RFC 6585. | Retry-After et la cadence d’appel. |
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-Typeindique le type de représentation, avec son encodage éventuel.Locationdonne une autre adresse, notamment pour une redirection ou une ressource créée.Cache-Control,ETagetLast-Modifiedparticipent au contrôle du cache.Allowliste les méthodes acceptées quand le serveur répond 405.Retry-Afterdonne 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.083967Le 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
Allowdonne 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.