00 - Pourquoi comprendre HTTP change tout

Ce que tu vas apprendre

• Pourquoi HTTP est le protocole que tu utilises le plus sans vraiment le connaître
• Ce qu'est HTTP au fond : du texte brut sur un fil
• Ce que cette serie de 21 articles couvre et dans quel ordre

Prerequisites

Aucun. Si tu sais ouvrir un terminal et taper une URL dans un navigateur, tu es pret.

Il y a quelques mois, un collegue me demande de l'aide sur un bug en production. Son frontend envoie un POST, le backend répond 200, mais les donnees ne sont pas enregistrees. Il me montre le code, les logs, les schemas de base. Tout a l'air correct. On a tourne en rond pendant une heure.

Et puis j'ai lance curl -v sur l'endpoint. La réponse du serveur etait la, en clair :

> POST /api/orders HTTP/1.1
> Host: api.example.com
> Content-Type: application/json
> Content-Length: 42
>
> {"product_id": 7, "quantity": 1}

< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 27
<
< {"status": "queued", "id": null}

"id": null. Le serveur acceptait la requête, repondait 200, mais ne creait rien. Un middleware de validation en amont rejetait silencieusement la commande et retournait un faux succes. Le bug etait invisible dans le code. Il etait visible dans le protocole.

Ce jour-la, j'ai réalisé un truc : la plupart des devs ne lisent jamais les échanges HTTP bruts. On utilise des abstractions -- fetch, axios, HttpClient -- et on fait confiance aux couches intermediaires. Quand ca marche, pas de problème. Quand ca casse, on est aveugle.

HTTP, c'est juste du texte

C'est la première chose a comprendre et probablement la plus sous-estimee. HTTP n'est pas un format binaire complique. C'est du texte ASCII envoye sur une connexion TCP. Une requête, c'est quelques lignes de texte. Une réponse aussi.

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

Ca, c'est une requête complète. Trois lignes. Un humain peut la lire, la comprendre, la taper a la main dans un terminal avec telnet ou nc. Rien de magique, rien de cache.

Evidemment, les choses se compliquent quand on ajoute le chiffrement (HTTPS), la compression (gzip), le multiplexage (HTTP/2), le binaire (HTTP/3). Mais le modèle mental reste le meme : un client envoie un message texte, un serveur répond avec un message texte.

Pourquoi cette serie existe

Parce que j'aurais aime avoir ces explications quand j'ai commence. Pas la RFC 7230 brute (meme si elle est bien écrite). Pas un cours universitaire. Juste un dev qui explique a un autre dev comment le protocole fonctionne, avec des exemples réels et des opinions tranchees.

Sur paltemps.fr, on debug régulièrement des problèmes qui semblent complexes mais qui se resolvent en 5 minutes des qu'on lit le trafic HTTP brut. Cette serie, c'est le socle que j'aurais voulu avoir.

Ce que couvre cette serie

Vingt et un articles, du fondamental au spécifique. Chaque article est independant mais la lecture dans l'ordre donne une vision complète.

Comment lire cette serie

Chaque article suit la meme structure. Un rappel de ce que tu vas apprendre, les prerequis, puis le contenu avec des exemples HTTP bruts que tu peux reproduire dans ton terminal. Je te recommande d'avoir curl installe et de tester au fur et a mesure.

Si tu es presse, les articles 00 a 07 couvrent l'essentiel. Le reste approfondit des sujets spécifiques que tu croiseras tot ou tard.

Résumé

• HTTP est un protocole texte lisible par un humain
• Comprendre HTTP brut te rend meilleur pour debugger
• Cette serie couvre le protocole de A a Z en 21 articles
• curl -v est ton meilleur ami

Suivant : 01 - Anatomie d'une URL

Sources

• RFC 9110 - HTTP Semantics
• MDN Web Docs - HTTP
• High Performance Browser Networking - Ilya Grigorik