HTTP

#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.

#Flow: sémantique des méthodesCopier le lien

#Exemple de requête (curl)Copier le lien

1curl -i https://example.com/

#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 → réponseCopier le lien

#QuizCopier 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

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

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

#Animation: cycle MISS → VALIDATE → HITCopier le lien

#Simulateur de cache (headers → 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