Perché Apache invia 200 OK mentre Ultima modifica corrisponde a If-modified-since?


10

Sto cercando di avere un comportamento di base per quanto riguarda la mia strategia di memorizzazione nella cache: i file devono essere memorizzati nella cache e riconvalidati ogni volta con il server. Quindi vorrei che Apache restituisse un 304.

Ecco la finestra di dialogo che si verifica per ogni aggiornamento del browser:

Status Code:200 OK

Request Headers

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie: ...
Host:...
If-Modified-Since:Tue, 14 Oct 2014 15:10:37 GMT
If-None-Match:"1461-505636af08fcd-gzip"
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Response Headers

Accept-Ranges:bytes
Cache-Control:No-cache
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:1412
Content-Type:text/html
Date:Tue, 14 Oct 2014 16:58:05 GMT
ETag:"1461-505636af08fcd-gzip"
Keep-Alive:timeout=5, max=99
Last-Modified:Tue, 14 Oct 2014 15:10:37 GMT
Server:Apache/2.4.6 (Ubuntu)
Vary:Accept-Encoding

(questo è da Chrome Devtools, con Disabilita cache deselezionata)

È possibile notare che la risposta contiene l'intestazione Cache-Control: No-cache e che l'intestazione If-modified-since corrisponde all'ultima modifica. Anche l'ETag corrisponde.

Apache non dovrebbe inviare un 304 in quel caso?

MODIFICARE

Disabilitare ETags in apache con

 Header  unset ETag

rende il comportamento della cache più prevedibile ...


Penso che abbia Cache-Control:max-age=0disabilitato la cache, quindi vedi la Cache-Control:No-cacherisposta.
TorioBR

Ho impostato esplicitamente Cache-Control: No-cache nella mia configurazione di Apache perché da w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 , ho capito che provoca una riconvalida per ogni richiesta. La riconvalida implica il rinvio del file? Direi che dovrebbe usare If-modified-since per determinare se è un 200 o un 304.
zrz

Risposte:


8

Questo sembra essere un vecchio bug , che spiega perché Header unset ETagfa la differenza.

Apache 2.4.0+ aggiunge automaticamente il nome del metodo di compressione a ETag (come si vede nelle intestazioni) e impedisce una risposta 304.

Le versioni più recenti di mod_deflate supportano un DeflateAlterETag che può essere utilizzato per controllare questo comportamento:

DeflateAlterETag NoChange

3
Questo è corretto ma Apache 2.4 non contiene questa opzione, solo Apache 2.5. Tuttavia personalmente non trovo ETags così utili poiché Apache li basa sull'ultima data modificata, piuttosto che sul contenuto del file. Quindi la disattivazione di ETags ritorna all'intestazione If-Modified-Since, che si basa comunque sulla data dell'ultima modifica. Puoi modificare ETag in Apache per renderlo basato su dimensione, ultima modifica e / o inode - con dimensione e ultima modifica predefinite - ma, fino a quando non aggiungono un'opzione per calcolare un ETag basato sul checksum del contenuto del file, è di uso limitato IMHO. Quindi li spengo.
Barry Pollard,

1
@BazzaDP Questo ha senso. 2.5 ha anche DeflateAlterETag Removeun'opzione per fare proprio questo
Mathias R. Jessen,

0

Questo si distingue nella richiesta come un po 'strano:

Cache-Control:max-age=0

Probabilmente più importante, noto che il contenuto restituito è html. Viene generato dinamicamente? Apache PUO 'inviare una risposta 304, ma a meno che non si stia offrendo contenuto statico, non è compito di Apache effettuare quella chiamata e dipende dalla logica dell'applicazione. Ad esempio, la maggior parte delle applicazioni php ha un supporto limitato per queste cose.

Una cache del front-end può essere utile, poiché l'app di memorizzazione nella cache può controllare il tempo di modifica, etag, ecc., Ma solo se sia l'applicazione che le intestazioni della richiesta sono compatibili con la cache. Ad esempio, l'applicazione deve impostare le intestazioni appropriate per indicare che il contenuto è memorizzabile nella cache e cose come l'intestazione del controllo della cache nella richiesta annulleranno la cache. Le intestazioni non sembrano compatibili con la cache.


Il file richiesto è un file html statico, per il quale Apache ottiene l'ora della modifica corretta. (Ultima modifica: mar, 14 ott 2014 15:10:37 GMT). l'intestazione max-age = 0 è nella richiesta inviata da Chrome quando scrivo l'URL e premo Invio. È lì a causa delle risposte precedenti?
zrz,

Ho letto che Chrome aggiunge automaticamente Cache-Control: max-age = 0 per richiedere (tranne che per la prima volta che carichi Chrome, digita l'URL, premi invio). Ma ciò non sembra influenzare altri server (i CDN inviano 304 anche con max-age = 0 nella richiesta).
zrz,

@zrz: limitare il caching intermedio è molto utile durante il debug, ma altrimenti danneggerebbe le prestazioni. Controlla il contesto di ciò che leggi su ciò che Chrome fa. In termini di ciò che fa apache, è abbastanza configurabile. Il controllo della cache è un'istruzione per le cache intermedie, non per il server di origine. Tuttavia, apache può fungere da cache intermedia e può essere configurato per fare qualsiasi cosa. Penso che se togli le tue istruzioni anti-caching otterrai un comportamento più simile a quello che ti aspetti da un server di origine.
MC0e,

0

Se hai configurato Apache con Cache-Control:No-cache, Apache non invierà mai un HTTP 304 Not modifiedclient.

Se si desidera riconvalidare alcune richieste, inserire un Cache-Control:No-cachesolo nelle pagine in cui è necessario. Non è necessario riconvalidare tutte le risorse e in questo modo si spreca la larghezza di banda.


Mi sembra confuso con il termine "revalidate". Per me significa verificare se è un 304. Sbaglio?
zrz,

Tui hai torto. La convalida è di inviare nuovamente tutti i dati al client e forzarlo a rileggere tutto, anche se ha già le stesse informazioni. Stai praticamente disabilitando la cache su ogni client.
TorioBR

Questo spiega molto. L'ultima cosa che devo spiegare tenendo presente che Apache invia 304 per alcune risorse (png per esempio), mentre ho ancora quel Cache-Control impostato no-cache nella risposta e max-age = 0 nella richiesta. Qualche idea?
zrz,

@ThoriumBR Se ti ho interpretato correttamente, entrambe le tue risposte non sono corrette qui; no-cache (al contrario di no-store) non significa "non memorizzare nella cache", e può risultare in un 304 se il contenuto non è cambiato. In effetti l'OP si aspettava questo, ma non lo stava ottenendo a causa del problema etag. must-revalidate si riferisce a come viene gestito il contenuto non aggiornato e non invia sempre "i dati tutti di nuovo".
Nick,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.