Anno 5 · Modulo 1 · Lezione 5

Codici di stato, cookie, sessioni ed evoluzione HTTP

Come il web ricorda chi sei: status code per dialogare con il server, cookie e sessioni per mantenere lo stato, e le rivoluzioni di HTTP/2 e HTTP/3 per la velocita.

🧪 Lab GitHub ⏱ 45 min 📚 Livello: Intermedio

🎯 Obiettivi di apprendimento

✓Classificare i codici di stato HTTP nelle 5 classi (1xx-5xx) e interpretare i piu comuni (200, 301, 400, 404, 500).

✓Spiegare perche HTTP e stateless e come cookie e sessioni risolvono il limite di memoria tra richieste.

✓Confrontare cookie vs sessioni per posizione, dimensione, durata, sicurezza e GDPR.

✓Descrivere le novita di HTTP/2 (multiplexing, header compression) e HTTP/3 (QUIC su UDP).

✓Leggere una response HTTP reale in DevTools e mappare status + Set-Cookie a comportamenti applicativi.

// Indice della lezione

1. I codici di stato HTTP: il linguaggio del server 2. HTTP e stateless: il vero problema 3. Cookie: memoria sul client 4. Sessioni: memoria sul server 5. Cookie vs Sessioni - confronto operativo 6. Evoluzione: da HTTP/1.0 a HTTP/3 7. Lettura pratica: DevTools + esempi 8. Verifica / Esercizio 9. Riepilogo e concetti chiave

1. I codici di stato HTTP: il linguaggio del server

📌 Definizione

Gli status code sono numeri a 3 cifre con cui il server comunica l'esito di una richiesta. La prima cifra identifica la classe; le altre due sono il dettaglio.

Ogni volta che richiedi una pagina, un'immagine o un'API, la prima riga della risposta contiene lo status: HTTP/1.1 200 OK. E' il modo piu veloce per capire se e andato tutto bene o cosa e andato storto.

1xx · INFO

Informativo

Richiesta ricevuta, continua. Es. 100 Continue usato quando invii un body grande.

2xx · SUCCESS

Successo

200 OK, 201 Created, 204 No Content (DELETE ok senza body).

3xx · REDIRECT

Redirezione

Devi andare altrove. 301 Moved Permanently (SEO), 302 Found / 307 Temporary Redirect.

4xx · CLIENT ERROR

Errore del client

400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests.

5xx · SERVER ERROR

Errore del server

500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

🎯 Esempio in classe

Apri jsonplaceholder.typicode.com/posts - F12 - Network - ricarica. Vedi 200 per la lista. Ora prova /posts/99999 - 404. POST senza Content-Type - 400. Ogni codice ti dice dove correggere: client o server.

HTTP · Esempi di Status Line

HTTP/1.1 200 OK
Content-Type: application/json

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-path

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer

HTTP/1.1 404 Not Found

HTTP/1.1 500 Internal Server Error

2. HTTP e stateless: il vero problema

📌 Definizione chiave

Stateless: il server non conserva memoria tra due richieste HTTP dello stesso client. Ogni request e autonoma.

Questo rende HTTP semplice e scalabile, ma crea un problema: come ricordare login, carrello, lingua preferita? Senza memoria, dovresti reinserire le credenziali ad ogni click.

I cookie sono piccoli file di testo salvati dal browser. Il server li imposta con Set-Cookie e il browser li rimanda automaticamente ad ogni richiesta successiva tramite header Cookie.

HTTP · Cookie header

-- Response del server:
HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600
Set-Cookie: theme=dark; Path=/; Max-Age=2592000

-- Request successiva del client (automatica):
GET /dashboard HTTP/1.1
Host: example.com
Cookie: sessionId=abc123; theme=dark

01 · TIPI

Session vs Persistente

Session cookie: dura fino a chiusura browser. Persistente: ha Expires/Max-Age, resta giorni/mesi.

02 · SIZE

Limiti

Max ~4KB per cookie, ~20 cookie per dominio. Non usarli per dati grandi.

03 · FLAG

Sicurezza

HttpOnly = non leggibile da JS (anti-XSS), Secure = solo HTTPS, SameSite=Lax/Strict = anti-CSRF.

⚠️ Errore comune in verifica

Dire che i cookie sono sicuri perche cifrati e sbagliato. Non lo sono di default! Vanno protetti con HttpOnly + Secure + SameSite. E il GDPR richiede consenso esplicito per quelli non tecnici (profilazione, analytics).

💬 Tip del docente

All'interrogazione: Dove sta il cookie? Sempre sul client. Chi lo decide? Il server con Set-Cookie. Se ti chiedono GDPR: tecnici = sempre permessi, profilazione = serve banner e consenso prima.

4. Sessioni: memoria sul server

Con le sessioni, i dati veri restano sul server. Al client viene dato solo un identificativo (session ID), spesso trasportato tramite cookie. Vantaggio: dimensione illimitata, dati mai esposti al browser.

NODE.JS / PHP · Sessione lato server

app.use(session({
  secret: 'chiave-segreta',
  cookie: { httpOnly: true, secure: true, sameSite: 'lax', maxAge: 3600000 }
}));
req.session.user = { id: 42, role: 'admin' };
req.session.cart = ['libro1', 'libro2'];

// PHP
session_start();
$_SESSION['user_id'] = 42;
$_SESSION['logged'] = true;
// browser riceve solo PHPSESSID=xxx

🎯 Esempio in classe

Lab Registro elettronico: login - server crea sessione con matricola e ruolo, invia cookie PHPSESSID. Chiudi browser - cookie sessione scade - devi rifare login. Se imposti Expires=7 giorni, resti loggato anche dopo chiusura.

5. Cookie vs Sessioni - confronto operativo

Caratteristica	Cookie	Sessione
Dove salvato	Client (browser/device)	Server (file, RAM, DB, Redis)
Cosa viaggia	Dati reali nel cookie	Solo ID sessione
Dimensione	Max 4KB per cookie	Illimitata
Durata	Session o persistente (Expires/Max-Age)	Configurata lato server
Eliminazione	Utente da browser o Expires passato	Lato server: destroy
Sicurezza	Esposto - serve HttpOnly/Secure	Piu sicuro
GDPR	Profilazione = consenso	Se usa cookie ID, stesso consenso
Uso tipico	Preferenze, tracking, theme	Login, carrello, dati sensibili

⚠️ Attenzione

Non salvare mai password in chiaro in un cookie! Per dati sensibili usa sessione lato server + cookie solo con ID firmato.

6. Evoluzione: da HTTP/1.0 a HTTP/3

📌 Perche evolve

HTTP nasce per pagine semplici. Oggi una pagina fa 100+ richieste. Le nuove versioni riducono latenza, overhead e connessioni, mantenendo stessa semantica (GET, POST, status non cambiano).

1996 · HTTP/1.0

Non persistente

1 richiesta = 1 connessione TCP. 10 immagini = 10 handshake - lentissimo.

1997 · HTTP/1.1

Persistente

keep-alive. Piu richieste sulla stessa TCP. Pipelining poco usato. Ancora diffuso.

2015 · HTTP/2

Multiplexing

Una TCP, molte stream parallele. Header compressi HPACK. Server Push. TLS.

HTTP/2: tutte le richieste viaggiano interleave in frame binari sulla stessa connessione. Header compressi: non rispedisci sempre Cookie e User-Agent per intero.

HTTP/3: passa a QUIC (UDP + critto integrata). Se perdi un pacchetto, non blocca gli altri stream (HOL blocking risolto). 0-RTT: seconda visita gia cifrata.

BASH · Verificare HTTP version

curl -I --http2 https://www.google.com -s | head -n 1
# HTTP/2 200
# In DevTools: Network > Protocol colonna -> h2, h3, http/1.1

7. Lettura pratica: DevTools + esempi

🎯 Lab GitHub

Usa jsonplaceholder.typicode.com + Postman. 1) GET /posts - 200, guarda Content-Type json. 2) POST /posts - 201. 3) Imposta Cookie: theme=light e osserva. 4) Application - Cookies: cancella e ricarica.

JAVASCRIPT · fetch con credenziali

const res = await fetch('https://jsonplaceholder.typicode.com/posts/1');
console.log(res.status, res.statusText);
if (!res.ok) throw new Error('HTTP ' + res.status);

fetch('https://api.example.com/me', { credentials: 'include' });

document.cookie = "theme=dark; Path=/; Max-Age=31536000; SameSite=Lax";
console.log(document.cookie);

💬 Trucco

301 + subito 200 = redirect permanente, guarda Location. 304 Not Modified = cache via ETag, non errore!

8. Verifica / Esercizio

🔬 Attivita pratica

E-commerce usa cookie per carrello ospite e sessione per login admin.

Utente aggiunge 3 prodotti senza login, chiude browser, riapre: trova ancora carrello? Dipende da cosa?
Admin login: PHPSESSID con HttpOnly; Secure; SameSite=Strict. Spiega ogni flag.
401 vs 403: differenza?
Perche 80 thumb piu veloce in HTTP/2?
503 su /checkout: colpa client o server? Cosa fai?

✅ Soluzione ragionata

1) Session cookie senza Expires - perso. Persistente Max-Age 7gg - resta. Robusto: cookie persistente + sync DB al login.

2) HttpOnly = JS non legge - anti-XSS. Secure = solo HTTPS - anti-sniffing. SameSite=Strict = non inviato cross-site - anti-CSRF.

3) 401 = non autenticato - login. 403 = autenticato ma non autorizzato - ruolo insufficiente.

4) HTTP/1.1 max 6 connessioni/dominio + coda. HTTP/2 multiplexa su 1 TCP parallelo + header compressi.

5) 503 server sovraccarico. Client retry backoff, messaggio temporaneamente non disponibile. Server: log, CPU, DB pool.

9. Riepilogo e concetti chiave

✓1xx info, 2xx successo (200,201,204), 3xx redirect (301,302), 4xx client (400,401,403,404,429), 5xx server (500,502,503).

✓HTTP stateless - senza memoria; cookie e sessioni mantengono stato.

✓Cookie = 4KB client-side, Set-Cookie/Cookie, session vs persistente, HttpOnly/Secure/SameSite, GDPR.

✓Sessione = dati su server, client solo ID; illimitata, piu sicura.

✓HTTP/1.1 persistente, HTTP/2 multiplexing + HPACK, HTTP/3 QUIC su UDP + 0-RTT.

📚 Prossimo passo - DNS: struttura, risoluzione, record

Ora che sai come client e server dialogano e si ricordano di te, vedrai come quel server viene trovato: DNS che traduce nomi in IP, con query ricorsive, record A, CNAME, MX e caching.

← Lezione precedenteIl protocollo HTTP - struttura Prossima lezione →DNS - struttura, risoluzione, record