#HTTPCopier le lien

Verbes, statuts, en-têtes, cookies/sessions; HTTP/2 multiplexé et HTTP/3 QUIC (aperçu). Comprendre les sémantiques permet d'écrire des clients/serveurs robustes et performants.

Objectifs d'apprentissage

• Choisir la bonne méthode (idempotence, sécurité sémantique) et codes de statut adaptés.
• Configurer cache et validation (Cache-Control, ETag) et comprendre Vary.
• Connaître les en-têtes de sécurité et la politique CORS côté navigateur.
• Distinguer HTTP/1.1 vs HTTP/2 (multiplexage) vs HTTP/3 (QUIC).

#Méthodes et sémantiquesCopier le lien

Les méthodes expriment l'intention. GET et HEAD sont sûres: elles ne modifient pas l'état et peuvent être mises en cache. PUT et DELETE sont idempotentes: les rejouer ne change pas l'état final; POST ne l'est pas par défaut et convient aux créations ou aux actions non idempotentes. PUT remplace une ressource entière, alors que PATCH applique des modifications partielles; il faut documenter le format et la sémantique pour éviter les ambiguïtés.

#Trace de référence: une requête et sa réponseCopier le lien

1$ curl -i https://api.example.com/data.json2GET /data.json HTTP/1.13Host: api.example.com4User-Agent: curl/8.5.05Accept: */*6 7HTTP/1.1 200 OK8Content-Type: application/json9Content-Length: 12810Cache-Control: public, max-age=6011ETag: "v1"12Vary: Accept-Encoding13 14{"items":[...]}

Tout le reste de cette page se lit sur cette trace: le statut (200), les en-têtes de cache (Cache-Control, ETag), la négociation (Accept/Content-Type). La version négociée apparaît dans la ligne de statut (HTTP/1.1) ou via ALPN pour HTTP/2/3.

#StatutsCopier le lien

Les familles de statuts structurent le dialogue: 2xx pour le succès, 3xx pour les redirections, 4xx pour les erreurs côté client et 5xx pour les erreurs côté serveur. Distinguer 401 Unauthorized (authentification requise) et 403 Forbidden (authentifié mais interdit) évite de brouiller les signaux côté client. Un 409 Conflict raconte un conflit métier explicite; 422 Unprocessable Entity décrit une demande bien formée mais invalide au regard du domaine.

#Animation: cycle requête puis réponseCopier le lien

#Caching web (pratique)Copier le lien

#CDN stepper (MISS/REVALIDATE/HIT)Copier le lien

Le cache économise de la bande passante et du temps, mais il doit être explicite. Cache-Control: max-age=3600, public autorise la réutilisation pendant une heure; no-store interdit tout stockage pour les données sensibles. La validation conditionnelle repose sur ETag/If-None-Match ou Last-Modified/If-Modified-Since et permet de répondre 304 Not Modified. Les variantes listées par Vary créent des clés de cache distinctes selon des en-têtes (langue, encodage, autorisation).

#Animation: décision de cacheCopier le lien

#Cookies, CORS et sécuritéCopier le lien

Les cookies de session portent des attributs de sécurité: Secure pour HTTPS, HttpOnly pour rester invisibles au JavaScript, SameSite pour réduire le CSRF. Le CORS autorise explicitement les origines à accéder aux réponses d'une API; il doit être restreint et cohérent avec l'usage des credentials. Les en-têtes comme Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy et Strict-Transport-Security améliorent la posture globale.

Le contrôle de concurrence côté HTTP se base sur les préconditions. If-Match avec un ETag empêche les mises à jour perdues: si l'étiquette ne correspond plus, la ressource a changé et le serveur renvoie 412 Precondition Failed.

#Lab: diagnostiquer le cache HTTPCopier le lien

Objectif: observer un hit, une revalidation 304, puis un miss contrôlé.

1. Première requête (MISS, création ETag):

1curl -i https://api.example.com/data.json

Réponse attendue: 200 OK avec ETag: "v1" et Cache-Control: public, max-age=60.

2. Requête conditionnelle avec If-None-Match (304 attendu):

1ETAG=$(curl -sI https://api.example.com/data.json | awk -F': ' '/^ETag/{print $2}')2curl -i -H "If-None-Match: $ETAG" https://api.example.com/data.json

Réponse attendue:

1HTTP/1.1 304 Not Modified2ETag: "v1"

Pas de corps: le client réutilise celui qu'il a en cache. C'est la signature exacte d'une revalidation réussie.

3. Simuler une nouvelle version (changer la ressource côté serveur), puis constater 200 avec un nouvel ETag.

#Simulateur de cache (en-têtes, résultat)Copier le lien

#Diagramme: MISS, VALIDATE, HIT (client, CDN, origine)Copier le lien

#Quiz éclairCopier le lien

#HTTP/2 et HTTP/3 (détails)Copier le lien

#Visualisation: priorités et multiplexage HTTP/2Copier le lien

HTTP/2 multiplexe plusieurs requêtes sur une seule connexion, compresse les en-têtes (HPACK) et propose des priorités; le « server push » a été déprécié côté navigateurs. HTTP/3 s'appuie sur QUIC (UDP), supprime le blocage de tête de ligne, prend en charge la migration de connexion lors d'un changement de réseau et permet un 0-RTT qui doit être employé avec prudence pour éviter les replays.

#Diagramme: HTTP/2 multiplexageCopier le lien

#Snippets: en-têtes de sécurité (Express)Copier le lien

1// À placer tôt dans votre pipeline (ou utilisez helmet en production)2app.use((req, res, next) => {3  res.set({4    // Force HTTPS côté navigateur (activer une fois tout prêt)5    'Strict-Transport-Security': 'max-age=31536000; includeSubDomains',6    // Politique CSP minimale (adapter selon vos besoins; privilégier nonce/sha256)7    'Content-Security-Policy': [8      "default-src 'self'",9      "base-uri 'self'",10      "object-src 'none'",11      "frame-ancestors 'none'",12      // Exemple avec nonce pour scripts dynamiques: script-src 'self' 'nonce-<nonce>'13    ].join('; '),14    // Empêche l'inférence de type

#HTTP/3 (QUIC): handshake et migration de connexionCopier le lien

#Diagnostic: quatre échecs HTTP typiques et leur signatureCopier le lien

• 502 Bad Gateway derrière un proxy (nginx, CDN): le proxy a joint l'amont mais la réponse est invalide ou la connexion a échoué. Le problème est derrière le proxy: santé du backend, timeout, protocole. curl -I direct sur le backend isole la cause.
• 504 Gateway Timeout: le proxy a bien transmis mais l'amont n'a pas répondu dans le délai. À distinguer de 502 (réponse cassée) et de 503 (surcharge déclarée, souvent avec Retry-After).
• 431/413 (en-têtes ou corps trop grands): la requête part complète mais un maillon (proxy, serveur) la rejette avant l'application; vérifiez la taille des cookies et les limites du serveur.
• Requête qui « refait » un POST après un timeout: un client HTTP qui rejoue sur timeout peut dupliquer une opération non idempotente; la parade est une clé d'idempotence applicative, pas un réglage HTTP.

Exercice écrit (corrigé): un appel GET /api/records renvoie 200 avec Cache-Control: no-store mais l'onglet Réseau montre « (from disk cache) ». Expliquez. Correction: no-store interdit le stockage; si le navigateur sert malgré tout du disque, c'est qu'une réponse antérieure sans no-store (ou une redirection intermédiaire mise en cache) a été réutilisée. Videz le cache, rejouez, et vérifiez avec curl -I que la réponse vue par le client porte bien no-store (un CDN peut l'avoir retirée).