HTTP : Les cartes postales qui font tourner le Web

En une phrase

Les messages HTTP sont des blocs de texte brut spécialement formatés que les clients (comme votre navigateur) et les serveurs utilisent pour se parler, pour demander et envoyer des pages web, des données, et des photos de chats à travers Internet.

Le problème que ça résout

À l'âge de pierre du numérique (fin des années 80 / début 90), Internet était un peu le Far West. Il y avait différents protocoles pour différentes tâches : FTP pour les fichiers, Gopher pour les menus de documents, et tout un tas d'autres systèmes de niche. Ils ne se parlaient pas vraiment entre eux. C'était comme avoir besoin d'un type de facteur et d'une enveloppe différents pour chaque personne que vous vouliez contacter.

Puis Sir Tim Berners-Lee est arrivé avec sa vision d'un « World Wide Web » — un système unifié de documents hypertexte liés. Pour que ça marche, il lui fallait un langage simple et universel que n'importe quel ordinateur pourrait utiliser pour demander un document et le recevoir. Il devait être sans état (stateless), ce qui signifie que chaque requête est un événement autonome, ne demandant pas au serveur de se souvenir des conversations passées. Et, point crucial, il devait être lisible par un humain, du moins en principe, pour faciliter le débogage.

C'est là qu'intervient le Hypertext Transfer Protocol, ou HTTP. Il a résolu le problème en définissant un format de message standard, une « carte postale » universelle pour le web. Cette carte postale a des emplacements désignés pour l'adresse du destinataire (le serveur et le chemin), les infos de l'expéditeur, une petite note sur ce qu'il y a dedans (les headers), et le contenu réel (le corps). Cette structure normalisée a permis à n'importe quel client de parler à n'importe quel serveur, créant ainsi le web interopérable que nous connaissons et aimons aujourd'hui.

Comment ça marche sous le capot

À la base, un message HTTP n'est qu'un flux de texte. Mais ce n'est pas n'importe quel texte ; il a une structure rigide. On ne peut pas juste griffonner « Donne-moi la page d'accueil ! » sur une serviette en papier numérique et la jeter à un serveur. Le message se décline en deux saveurs principales : la requête (la demande) et la réponse (ce qui est donné en retour).

Anatomie d'une requête

C'est ce que votre navigateur envoie quand vous tapez une URL ou cliquez sur un lien. Elle est composée de trois parties au maximum, séparées par des sauts de ligne spécifiques (CRLF, ou \r\n en code).

Ligne de départ (Start-Line) : Une seule ligne qui dit ce que vous voulez, où ça se trouve, et quelle version du langage vous parlez. MÉTHODE /chemin/vers/la/ressource HTTP/Version

GET /documentation/guides/http HTTP/1.1

GET est la Méthode. C'est le verbe de la requête.
/documentation/guides/http est le Chemin de la ressource.
HTTP/1.1 est la Version du protocole.

Méthode courante	Signification	A un corps ?
`GET`	« S'il te plaît, donne-moi cette ressource. »	Non
`POST`	« Voici des données ; crée quelque chose. »	Oui
`PUT`	« Voici des données ; mets à jour/remplace. »	Oui
`DELETE`	« S'il te plaît, supprime cette ressource. »	Non
`HEAD`	« Donne-moi juste les headers, pas le corps. »	Non

Headers : Une série de paires Clé: Valeur qui fournissent des métadonnées sur la requête. Voyez-les comme les cases à cocher et les notes au dos de la carte postale.
```
Host: flowing.dev
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
```
- Host: Le plus important. Il indique au serveur quel site web vous essayez d'atteindre, ce qui est essentiel pour les serveurs hébergeant plusieurs sites sur une seule adresse IP.
- User-Agent: « C'est le navigateur/l'outil que j'utilise. »
- Accept: « Je préfère recevoir le contenu dans ces formats. »
L'indispensable ligne vide : Après le dernier header, il y a une unique ligne complètement vide (CRLF). C'est le séparateur non négociable. Il signale : « Fin des headers, le corps (s'il y en a un) commence juste après. »
Corps (Optionnel) : Le payload. Pour les requêtes GET ou HEAD, il est vide. Pour un POST ou un PUT, c'est là que se trouvent les données que vous envoyez — le payload JSON d'un appel d'API, le contenu d'un formulaire, etc.
```
{
  "username": "dev-guru",
  "email": "guru@example.com"
}
```

Anatomie d'une réponse

C'est ce que le serveur renvoie. Elle reflète la structure de la requête, mais son rôle est différent.

Ligne de statut (Status-Line) : Une seule ligne qui vous dit si la requête a fonctionné et pourquoi. HTTP/Version StatusCode StatusText

HTTP/1.1 200 OK

Le StatusCode est la partie la plus critique. C'est un nombre à trois chiffres qui résume le résultat.

Famille de code	Signification	Exemple
`2xx`	Succès ! Tout a fonctionné.	`200 OK`
`3xx`	Redirection. Vous devez chercher ailleurs.	`301 Moved Permanently`
`4xx`	Erreur client. Vous avez fait une erreur.	`404 Not Found`
`5xx`	Erreur serveur. J'ai fait une erreur.	`500 Internal Server Error`

Headers : Des paires Clé: Valeur décrivant la réponse.
```
Date: Fri, 24 May 2024 12:00:00 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 4096
Cache-Control: max-age=600
```
- Content-Type: « Voici ce que je t'envoie. Dans ce cas, un document HTML encodé en UTF-8. »
- Content-Length: « Le corps de ma réponse fait exactement 4096 octets. »
- Cache-Control: « Toi (ou n'importe quel proxy sur le chemin) peux stocker une copie de ceci pendant 600 secondes. »
La ligne vide : Eh oui, elle est là aussi. Elle sépare les headers du corps.
Corps : La chose que vous avez vraiment demandée ! Le HTML de la page web, les données JSON de l'API, le fichier image, etc. C'est le « contenu » de Content-Type.

Histoires vécues

Le cas du mystérieux 401

Une développeuse intégrait une API tierce. Elle était sûre d'envoyer la bonne clé d'API, mais chaque requête revenait avec une erreur 401 Unauthorized. Son code semblait parfait : api.setAuth('my-secret-key'). Frustrée, elle a capturé la requête HTTP brute envoyée par son framework.

Le message brut a révélé la vérité :

POST /v1/widgets HTTP/1.1
Host: api.thirdparty.com
Content-Type: application/json
Api-Key: my-secret-key

{ "name": "New Widget" }

Elle a relu la documentation de l'API. Le header d'authentification devait être Authorization, et non Api-Key, et la valeur devait être préfixée par Bearer . L'abstraction de son framework était trop simpliste et utilisait le mauvais nom de header. Elle a passé outre la méthode utilitaire, a défini le header manuellement, et la requête suivante est passée sans problème avec un 201 Created.

Leçon : Les frameworks et les bibliothèques sont des abstractions utiles, mais le message HTTP brut est la source de vérité. Quand quelque chose semble clocher, inspectez le message brut pour voir ce qui est réellement envoyé sur le réseau.

Le casse-tête de la mise en cache

Une équipe marketing a lancé une nouvelle landing page, mais la moitié de l'entreprise voyait encore l'ancienne page « Bientôt disponible », même après avoir martelé Ctrl+F5 frénétiquement. Le développeur insistait sur le fait que ce n'était pas un problème de code côté serveur. Suspectant un problème de cache, il a utilisé un outil pour inspecter les headers de la réponse HTTP brute de la page.

La réponse du serveur ressemblait à ceci :

HTTP/1.1 200 OK
Content-Type: text/html
...
Cache-Control: public, max-age=86400
Age: 34500

Le header Cache-Control disait à chaque navigateur et serveur proxy de la chaîne de conserver cette page pendant 86 400 secondes (une journée entière !). Le header Age montrait que la version servie avait déjà plus de 9 heures. Un paramètre mal configuré sur leur CDN (Content Delivery Network) appliquait une politique de mise en cache agressive à toutes les pages HTML. Une fois qu'ils ont corrigé la règle du CDN, la nouvelle page est apparue instantanément pour tout le monde.

Leçon : Les headers de réponse ne sont pas que des métadonnées ; ce sont des instructions qui contrôlent les navigateurs, les proxys et les CDN. Comprendre Cache-Control, Expires et ETag est crucial pour gérer la manière dont votre contenu est distribué.

Le voleur de corps silencieux

Un développeur junior a créé un endpoint d'API simple pour accepter les retours des utilisateurs. Cela fonctionnait parfaitement sur sa machine locale. Mais dans l'environnement de staging, les soumissions de formulaire échouaient. Les logs du serveur montraient que les requêtes POST /feedback arrivaient bien, mais le corps de la requête était toujours vide. Les données de l'utilisateur se volatilisaient dans la nature.

Perplexe, il a « dumpé » l'intégralité de la requête HTTP brute telle qu'elle arrivait au serveur. Pour une soumission de test, il a vu ceci :

POST /feedback HTTP/1.1
Host: staging.myapp.com
Content-Type: application/json
Content-Length: 0

{}

Mais il savait que son code côté client envoyait un objet JSON complet ! Le Content-Length était de 0 et le corps était vide. En remontant la chaîne, il a découvert une règle de sécurité dans le pare-feu applicatif web (WAF) de l'environnement de staging qui était configurée par erreur pour supprimer le corps de toute requête POST vers un chemin inconnu. Comme /feedback était un nouveau endpoint, le WAF « protégeait » le serveur en mangeant silencieusement les données.

Leçon : Les headers Content-Length et Content-Type sont un contrat entre le client et le serveur. S'ils ne décrivent pas précisément le corps, les choses se casseront de manière déroutante. Vérifiez-les toujours lors du débogage de problèmes de transmission de données.

Erreurs et pièges courants

Oublier la ligne vide. Cette ligne vide (CRLFCRLF) entre les headers et le corps n'est pas un simple espace optionnel. C'est le séparateur fondamental. Sans elle, le message entier est malformé, et un serveur ne saura pas où les headers se terminent et où le payload commence.
Content-Length incohérent. Si votre header dit Content-Length: 100 mais que vous n'envoyez qu'un corps de 50 octets, le serveur restera bloqué en attendant les 50 autres octets jusqu'à l'expiration du délai (timeout). Si vous envoyez 150 octets, les 50 octets supplémentaires pourraient être mal interprétés comme le début d'une nouvelle requête corrompue.
Fins de ligne CRLF vs LF. La spécification HTTP est rigide : les lignes doivent se terminer par un retour chariot suivi d'un saut de ligne (\r\n). Bien que de nombreux serveurs modernes soient indulgents et acceptent un simple saut de ligne (\n), certains serveurs plus anciens ou plus stricts rejetteront le message ou le parseront incorrectement.
Ignorer Content-Type. Vous pouvez envoyer un objet JSON parfaitement valide dans le corps de votre POST, mais si vous n'incluez pas le header Content-Type: application/json, le serveur pourrait supposer qu'il s'agit de application/x-www-form-urlencoded (la valeur par défaut pour les formulaires) et ne pas réussir à le parser.
Confusion sur la casse des headers. Les noms de headers sont insensibles à la casse (Content-Type est identique à content-type). Cependant, les valeurs des headers peuvent être, et sont souvent, sensibles à la casse. Une clé d'API ou une valeur encodée en Base64 en est un excellent exemple.

Pourquoi vous devriez garder ça à l'œil

Si vous touchez de près ou de loin au développement web, à la conception d'API ou même à la sécurité réseau, comprendre les messages HTTP bruts n'est pas optionnel, c'est fondamental. Vos frameworks et bibliothèques de haut niveau font un excellent travail pour masquer les détails techniques, mais quand ils échouent ou se comportent de manière inattendue, vous devez être capable de retirer les couches successives et de regarder la communication brute.

Vous devriez penser au message HTTP brut chaque fois que vous :

Déboguez une erreur liée au réseau (codes 4xx ou 5xx).
Essayez d'optimiser les performances web (mise en cache, compression).
Construisez ou consommez une API.
Configurez des redirections, des proxys ou des load balancers.
Enquêtez sur des vulnérabilités de sécurité web (par exemple, l'injection de header).

Savoir lire et interpréter ces messages, c'est comme un mécanicien qui connaît le fonctionnement d'un moteur. Vous n'avez pas besoin d'y penser chaque fois que vous conduisez, mais quand la voiture tombe en panne, c'est le seul moyen de comprendre ce qui se passe vraiment.

Pour aller plus loin

MDN : Une vue d'ensemble de HTTP - Le meilleur point de départ, alliant clarté et précision technique.
RFC 9110: HTTP Semantics - La spécification moderne des concepts de base de HTTP comme les méthodes, les codes de statut et les headers. (en anglais)
RFC 9112: HTTP/1.1 - La spécification qui définit la syntaxe des messages textuels que nous avons vue ici. (en anglais)
Wikipedia: Hypertext Transfer Protocol - Un bon résumé de haut niveau sur l'histoire et les composants de HTTP.
HTTP/2 Explained - Un livre en ligne gratuit par Daniel Stenberg (le créateur de cURL) qui explique comment les concepts fondamentaux des messages HTTP sont adaptés pour le protocole moderne et binaire HTTP/2. (en anglais)