304 Not Modified: perché è un successo, non un errore

Come si arriva a un 304

Un 304 è la seconda metà di una conversazione in due passaggi. Alla prima richiesta il server restituisce la risorsa con un validatore: un ETag, che è un identificatore opaco per quella versione esatta, e spesso una data Last-Modified. Il client memorizza la risposta insieme a questi validatori.

In seguito, quando la copia in cache deve essere rivalidata, il client ripete la richiesta includendo ciò che possiede:

• If-None-Match: "abc123" trasporta l'ETag memorizzato. È il validatore preferito perché è esatto.
• If-Modified-Since: Wed, 03 Sep 2026 10:00:00 GMT trasporta la data memorizzata, usata quando non c'è un ETag.

Se la risorsa non è cambiata, il server risponde 304 Not Modified con sole intestazioni e nessun corpo, e il client mostra la propria copia in cache. Se è cambiata, il server risponde 200 con il nuovo contenuto e nuovi validatori. Entrambi gli esiti sono un comportamento corretto.

Perché un 304 è una buona notizia, non un errore

Le persone vedono un 304 nel pannello di rete del browser o in un analizzatore di log, notano che non è un 200, e pensano che qualcosa sia fallito. Non è così. Un 304 è la risposta utile più economica del web: nessun corpo di risposta attraversa la rete, quindi il trasferimento è di poche centinaia di byte invece dell'intero asset, e il server di solito evita di rigenerare la risorsa, quindi costa meno CPU di quanto costerebbe un 200. La pagina si carica più velocemente perché il browser riutilizza byte che ha già. Ne beneficiano anche i crawler, perché un ETag stabile che produce 304 permette a un motore di ricerca di spendere il proprio crawl budget sulle pagine che sono davvero cambiate.

Un'alta proporzione di 304 sugli asset statici è un segno che la cache è configurata bene. L'unica cosa da tenere d'occhio è se hai davvero bisogno del round trip di rivalidazione: per asset versionati o con fingerprint, un lungo Cache-Control: max-age con immutable evita perfino il 304, perché il browser non lo chiede nemmeno.

Quando un 304 è un problema

• Una pagina obsoleta che non si aggiorna. Se il tuo HTML viene servito con un validatore che non cambia mai mentre il contenuto sì, i browser continuano a ricevere 304 e gli utenti continuano a vedere la pagina vecchia. È il classico bug "ho fatto il deploy ma nessuno lo vede".
• Un 304 senza una copia in cache corrispondente. Se un client invia una richiesta condizionale senza averne motivo, o un proxy rimuove il corpo da un 200, il client resta senza nulla da mostrare e la pagina appare vuota.
• ETag deboli o instabili dietro un load balancer. Quando più backend generano ETag diversi per contenuti identici, ogni rivalidazione fallisce e ottieni 200 completi dove ti aspettavi 304. Il traffico aumenta senza motivo.
• La compressione che cambia il validatore. Se l'ETag differisce tra le varianti compresse e non compresse senza un corretto Vary: Accept-Encoding, le cache possono servire la cosa sbagliata.

Come testare le richieste condizionali

1. Recupera la risorsa e leggi i suoi validatori:

   curl -sI https://example.com/style.css | grep -Ei "^(HTTP|etag|last-modified|cache-control)"

2. Ripeti la richiesta con l'ETag che hai ottenuto e conferma che il server risponde 304:

   curl -sI -H 'If-None-Match: "abc123"' https://example.com/style.css | head -n 1

   Sostituisci il valore esatto dell'ETag, virgolette incluse. Un 200 qui significa che la rivalidazione non funziona.
3. Se ottieni 200 quando ti aspettavi 304, controlla se un proxy o una CDN sta rimuovendo If-None-Match, e se i tuoi backend concordano sull'ETag per lo stesso file.
4. Se ottieni una pagina obsoleta, fai cambiare il validatore quando cambia il contenuto. I nomi file con fingerprint sono la soluzione più affidabile; altrimenti deriva l'ETag dal contenuto stesso.
5. Tieni l'HTML su una durata di freschezza breve e lascia che gli asset portino quella lunga. Un HTML messo in cache per un giorno è ciò che rende invisibile un deploy.

Perché i controlli di uptime non vedono mai un 304

Un controllo di uptime richiede una pagina come un visitatore alla prima visita, senza If-None-Match e senza If-Modified-Since, quindi il server non ha nulla con cui confrontare e risponde sempre 200. È il comportamento predefinito corretto per la disponibilità. Significa anche che le regressioni della cache non compaiono affatto nei dati di uptime: un sito può servire a tutti una pagina obsoleta mentre ogni controllo resta verde. Fai un assert sul contenuto della pagina oltre che sullo stato, e una pagina che ha smesso di aggiornarsi diventa visibile come una discrepanza di contenuto. HostTracker offre 13 tipi di monitor e monitora siti web dal 2004. Testa intestazioni e stato con lo strumento di controllo HTTP, e leggi cosa dimostra davvero un 200 OK e la guida completa alla famiglia 3xx.