ETag

Un ETag (Entity Tag) è un’intestazione di risposta HTTP — tipicamente un hash o un timbro di versione del corpo della risposta — che permette a un client di rivalidare una risorsa in cache senza riscaricaria.

Flusso di lavoro:

1. Prima richiesta: il server restituisce la risorsa con ETag: "abc123".
2. Il client memorizza nella cache la risposta con l’ETag.
3. Richiesta successiva: il client invia If-None-Match: "abc123".
4. Il server confronta l’ETag corrente con quello del client. Se uguale: 304 Not Modified con corpo vuoto, il client usa la sua copia in cache. Se diverso: 200 OK con il nuovo corpo e il nuovo ETag.

Due varianti di ETag:

• ETag strong — cambiano se cambiano i byte. Predefinito.
• ETag weak — prefissati con W/, possono corrispondere tra risposte “semanticamente equivalenti” (ad es., compresse vs non compresse dello stesso contenuto).

ETag è uno dei tre meccanismi di validazione della cache HTTP (insieme a Last-Modified + If-Modified-Since e Cache-Control max-age). Per i siti statici moderni con URL degli asset con hash del contenuto, ETag è raramente necessario — ma rimane il cavallo di battaglia per le API dinamiche che vogliono il caching lato client.

Esempio pratico

Un browser recupera /api/profile per la prima volta. Il server risponde: HTTP/1.1 200 OK, ETag: "v42-7a8b9c", corpo = 4,2 KB di JSON. Il browser memorizza entrambi nella cache. Al successivo caricamento della pagina, il browser invia GET /api/profile con If-None-Match: "v42-7a8b9c". Il server calcola l’ETag corrente — ancora "v42-7a8b9c" perché nulla è cambiato — e risponde HTTP/1.1 304 Not Modified con zero byte di corpo. Il browser serve la sua copia in cache. Banda risparmiata: 4,2 KB; latenza di andata e ritorno ancora pagata. Confrontando con Cache-Control: max-age=300, che salta completamente l’andata e ritorno per 5 minuti — si vede perché ETag è la seconda migliore strategia di caching: conferma la freschezza quando non è ammessa la obsolescenza, ma non risparmia effettivamente il round-trip di rete. I siti statici moderni preferiscono URL con fingerprint + max-age a lungo termine e saltano ETag del tutto.

Quando e perché è importante

ETag è importante per due flussi di lavoro distinti: la rivalidazione della cache (risparmiare banda quando le risposte sono grandi e invariate) e il controllo ottimistico della concorrenza (prevenire bug di aggiornamento perso nelle API REST). L’errore da evitare nel caching è generare un ETag weak da un timestamp che include precisione sub-secondo — ogni server in un cluster bilanciato calcola un valore diverso per la stessa risorsa e i client invalidano costantemente. Usare un hash stabile del contenuto (SHA-256 del corpo, spesso troncato a 16 caratteri) in modo che tutte le repliche producano lo stesso ETag. L’errore da evitare nella concorrenza è non validare If-Match lato server — molti sviluppatori aggiungono l’intestazione nelle scritture ma il server la ignora, lasciando irrisolto la race condition. AWS S3, Google Cloud Storage e l’API di Stripe applicano tutti rigorosamente la concorrenza basata su ETag; seguire il loro schema è il design di riferimento più sicuro. Riferimento: MDN — ETag HTTP header.

Controllo ottimistico della concorrenza — il secondo compito dell’ETag: ETag è anche il meccanismo standard per “non sovrascrivere i miei dati se qualcun altro li ha modificati”. Il client esegue GET sulla risorsa, cattura l’ETag, apporta modifiche, poi esegue PUT con If-Match: "abc123". Se la risorsa lato server è cambiata nel frattempo (ETag diverso), il server restituisce 412 Precondition Failed e il client sa di dover aggiornare e rifondere. AWS S3, Google Cloud Storage e la maggior parte delle API REST che supportano modifiche concorrenti usano esattamente questo schema.

Il problema della privacy con gli ETag: i server possono usare valori ETag unici per utente (essenzialmente un cookie emesso dal server incorporato nei metadati della cache) per tracciare gli utenti di ritorno senza impostare un cookie reale — il cosiddetto “ETag cookie” o “supercookie”. Anche dopo che un utente svuota i cookie, il browser invia ancora l’ETag alla richiesta successiva, identificandolo. I browser ora partizionano le cache HTTP per sito di livello superiore (Chrome 86, Firefox 85) per neutralizzare questo attacco, ma la tecnica rimane una nota di privacy nella progettazione del caching HTTP. Riferimento: RFC 9110 §8.8.3 — ETag.