En-têtes, JSON et cookies
En-têtes clés, JSON et mécanisme des cookies.
Objectifs
À la fin de cette leçon, vous saurez :
- utiliser les en-têtes qui reviennent tous les jours ;
- structurer des données avec JSON dans le corps ;
- comprendre le mécanisme des cookies vu du protocole.
Les en-têtes indispensables
Côté requête :
Host: exemple.fr ← quel site (obligatoire en HTTP/1.1)
Content-Type: application/json ← ce que j'envoie
Authorization: Bearer <jeton> ← qui je suis
Accept: application/json ← ce que je souhaite recevoir
Cookie: session=abc123 ← mon identifiant de session
Côté réponse :
Content-Type: application/json; charset=utf-8 ← ce que je t'envoie
Content-Length: 34 ← sa taille
Set-Cookie: session=xyz; HttpOnly ← « retiens ceci »
Cache-Control: no-cache ← politique de cache
Location: /users/42 ← où trouver la nouvelle ressource (avec 201)
Le couple Content-Type est le contrat de format : l'envoyer faux est la source classique d'erreurs 400 incompréhensibles.
JSON : le langage des corps
{
"id": 42,
"name": "Paul",
"tags": ["admin", "beta"],
"address": { "city": "Lyon" },
"active": true,
"avatar": null
}
Règles : clés entre guillemets, valeurs parmi chaîne/nombre/booléen/null/tableau/objet. C'est le format universel des API modernes : lisible par les humains et parsable partout.
Les cookies vus du protocole
Mécanisme complet en deux temps :
1. réponse Set-Cookie: session=xyz; HttpOnly; Secure
2. requêtes suivantes Cookie: session=xyz
Le serveur suggère, le navigateur stocke et rejoue automatiquement. Attributes importants :
| Attribut | Effet |
|---|---|
HttpOnly | inaccessible au JavaScript (protection XSS) |
Secure | envoyé uniquement en HTTPS |
SameSite=Lax|None | contrôle l'envoi depuis d'autres sites (protection CSRF) |
Max-Age / Expires | durée de vie |
Retenez le lien avec le chapitre HTTP précédent : les cookies réintroduisent la continuité dans un protocole sans état. Vos futures sessions applicatives reposeront exactement là-dessus.
Exercice
- Écrivez la requête POST minimale pour créer un utilisateur
{ "name": "Paul" }. - Un serveur renvoie
Content-Type: text/htmlalors que vous attendiez du JSON. Qu'est-ce que cela suggère ? - Pourquoi
HttpOnlyprotège-t-il contre le vol de session par XSS ?
Résumé
- En-têtes = métadonnées ; Content-Type = contrat de format.
- JSON : structure universelle des corps d'API.
- Cookie = convention stockée/rejouée par le navigateur ; ses attributs sont des garde-fous.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1.
POST /users HTTP/1.1
Host: exemple.fr
Content-Type: application/json
{"name": "Paul"}
La ligne vide entre les en-têtes et le corps est obligatoire.
Question 2. Soit l'URL ne pointe pas vers l'API (page HTML d'erreur), soit le serveur a un bug de configuration. Premier réflexe : lire le corps réel de la réponse — il contient souvent une page d'erreur explicite.
Question 3. Une injection XSS exécute du JavaScript sur la page ; sans HttpOnly, document.cookie donnerait accès au jeton de session. Avec lui, le cookie reste invisible au script tout en continuant à circuler vers le serveur.