HTTP 304 Not Modified, simulato richiesta per richiesta
HTTP 304 Not Modified
HTTP 304 Not Modified: ETag e If-None-Match spiegati | We.Inc
Simula una richiesta condizionale: imposta ETag e Last-Modified del server, If-None-Match e If-Modified-Since del browser, e vedi 304 o 200 con il motivo.
Una risposta 304 Not Modified dice al browser che la sua copia in cache è ancora aggiornata, quindi il server evita di inviare di nuovo il body. Risponde a una GET o HEAD condizionale che conteneva If-None-Match o If-Modified-Since. Un 304 è una buona notizia, non un errore: fa risparmiare banda mentre il file in cache continua a essere usato.
Le coppie di validatori dietro un 304
Il server invia
Il browser rimanda
Il server risponde 304 quando
ETag: "v2"
If-None-Match: "v2"
Un tag elencato corrisponde all'ETag attuale (confronto debole)
Last-Modified: <date>
If-Modified-Since: <date>
La risorsa non è cambiata da quella data
Entrambi
Entrambi
Decide If-None-Match; If-Modified-Since viene ignorato
Compila ciò che il server ha in questo momento e ciò che invia il browser, e il simulatore applica le regole di precedenza della specifica HTTP. Mostra lo stato che il server dovrebbe restituire e quale header lo ha determinato. Svuota un campo per omettere quell'header.
Imposta i valori ETag e Last-Modified che il server ha ora per il file.
Imposta gli header If-None-Match e If-Modified-Since che il browser invia dalla sua cache.
Leggi lo stato e il motivo: quale header è stato valutato e perché corrispondeva o no.
Cambia l'ETag del server per vedere come un deploy trasforma la richiesta successiva in un 200.
Un 304 deve ripetere gli header come Cache-Control, ETag, Vary e Date che avrebbe un 200, così la cache può aggiornare i metadati salvati.
Nomi di asset con impronta come app.3f9a1c.js più un max-age lungo evitano del tutto la rivalidazione. Tieni la rivalidazione con ETag per l'HTML e le risposte delle API.
Gli ETag deboli iniziano con W/ e garantiscono equivalenza semantica, non uguaglianza byte per byte. Funzionano comunque con If-None-Match perché quell'header usa il confronto debole.
Nei DevTools, una riga 304 con una piccola dimensione di trasferimento indica che il browser ha rivalidato con successo. Disattiva la cache nel pannello Network per forzare risposte 200 complete durante il debug.
Domande frequenti
Una risposta 304 è un errore?
No. È uno stato della classe dei reindirizzamenti che significa che la copia in cache può essere usata. Il browser mostra la pagina dalla sua cache, e in rete sono passati solo gli header.
Una risposta 304 può avere un body?
No. La specifica dice che una risposta 304 termina alla fine della sezione degli header e non può contenere contenuto.
Chi vince, If-None-Match o If-Modified-Since?
If-None-Match. Quando una richiesta li contiene entrambi, un server che supporta gli entity tag valuta If-None-Match e ignora If-Modified-Since, perché i tag rilevano modifiche che una data con precisione di un secondo non può cogliere.
Perché ricevo 200 invece di 304 dopo ogni deploy?
Il deploy ha cambiato il file o il suo ETag, quindi il tag che ha il browser non corrisponde più. È il comportamento corretto. Se anche i file non modificati perdono il loro 304, controlla se i tuoi server generano ETag diversi per lo stesso contenuto.
Una POST può mai restituire 304?
No. If-None-Match e If-Modified-Since producono 304 solo per GET e HEAD. Per gli altri metodi una condizione non soddisfatta dà 412 Precondition Failed.
Come funziona la rivalidazione
Quando una risposta in cache diventa obsoleta, il browser non la butta via. Chiede al server se la sua copia è ancora valida inviando i validatori che ha salvato: l'ETag come If-None-Match, la data Last-Modified come If-Modified-Since.
Se non è cambiato nulla, il server risponde 304 con header aggiornati e senza body, e il browser continua a usare la sua copia. Se qualcosa è cambiato, il server invia un normale 200 con il nuovo contenuto.
Tag forti e deboli
Un tag forte come "v2" garantisce che i byte siano identici. Un tag debole come W/"v2" garantisce solo che il contenuto sia equivalente. If-None-Match esegue un confronto debole, quindi lì W/"v2" e "v2" contano come corrispondenza; If-Match esegue un confronto forte e non li considererebbe uguali.
Lo scambio in rete
Prima visita: 200 con i validatori
Il server fornisce un ETag e una data Last-Modified insieme al contenuto.
Visita successiva: 304 senza body
Il browser rimanda il tag salvato e riceve solo gli header.
Rispondere da soli alle richieste condizionali
Server http di Node con un ETag basato sull'hash del contenuto
Calcola l'hash del body, lo confronta con If-None-Match e invia 304 senza body se corrisponde.
Simulatore di richieste condizionali
Cosa ha ora il server
Cosa invia il browser
ETag
Last-Modified
If-None-Match
If-Modified-Since
Risposta del server
If-None-Match elenca un tag che corrisponde all'ETag attuale con il confronto debole, quindi la copia in cache è aggiornata.
If-None-Match è *, e la risorsa esiste, quindi la condizione è falsa.
Nessun tag in If-None-Match corrisponde all'ETag attuale, quindi il server invia il nuovo contenuto. If-Modified-Since non viene controllato.
Non c'è If-None-Match, e Last-Modified non è successivo a If-Modified-Since.
Non c'è If-None-Match, e Last-Modified è successivo a If-Modified-Since.
If-Modified-Since è presente ma una delle due date non è leggibile, quindi l'header viene ignorato.
La richiesta non ha validatori, quindi è una richiesta normale.