Controllo della cache del browser, contenuto dinamico

Question

Problema: Non riesco a convincere FireFox a memorizzare nella cache le immagini inviate da un server dinamico

Impostare: Server Apache statico con proxy inverso a un server dinamico (mod_perl2) nel backend.

Ecco l'URL della richiesta per il server.Viene inviato al server dinamico, dove il cookie viene utilizzato per convalidare l'accesso all'immagine:

Richiedi intestazioni

Host:  <OBSCURED>
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept:  image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset:  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:  300
Connection:  keep-alive
Referer: <OBSCURED>
Cookie:  pz_cred=4KCNr0RM15%2FJCOt%2BEa6%2BL62z%2Fxvbp2xNQHY5pJw5d6Q
Pragma:  no-cache
Cache-Control: no-cache

Il server dinamico trasmette l'immagine al server e fornisce la seguente risposta:

Intestazioni di risposta

Date:  Tue, 24 Nov 2009 04:28:07 GMT
Server:  Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
Cache-Control: public, max-age=31536000
Content-Length:  25496
Content-Type:  image/jpeg
Via: 1.1 127.0.1.1:8081
Keep-Alive:  timeout=15, max=75
Connection:  Keep-Alive

Fin qui tutto bene (secondo me).Tuttavia, al ricaricamento della pagina, l'immagine non viene visualizzata nella cache e viene nuovamente inviata una richiesta:

Richiedi intestazioni

Host: <OBSCURED>
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept:  image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset:  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:  300
Connection:  keep-alive
Referer: <OBSCURED>
Cookie:  pz_cred=4KCNr0RM15%2FJCOt%2BEa6%2BL62z%2Fxvbp2xNQHY5pJw5d6Q
Cache-Control: max-age=0

Non sembra che la richiesta dovrebbe avvenire poiché il browser avrebbe dovuto memorizzare nella cache l'immagine.Così com'è, viene ricevuta una risposta 200, identica alla prima, e l'immagine sembra essere recuperata nuovamente (anche se sembra che il browser utilizzi le immagini memorizzate nella cache).

Il problema sembra essere accennato dal Cache-Control:max-age=0 nell'intestazione della richiesta di ricarica, sopra.

Qualcuno sa perché questo sta accadendo?Forse è il attraverso intestazione nella risposta che causa il problema?

Answer 1

La mia risposta precedente era solo parzialmente corretta.

Il problema è il modo in cui FireFox 3 gestisce gli eventi di ricaricamento.Apparentemente, richiede quasi sempre nuovamente il contenuto dal server di origine.Così il Cache-Control: max-age=0 intestazione della richiesta.

Firefox fa utilizza le immagini memorizzate nella cache per eseguire il rendering di una pagina al ricaricamento, ma poi effettua comunque tutte le richieste per aggiornarle "in background".Quindi li sostituisce non appena entrano.

Pertanto, la pagina viene visualizzata velocemente, YSlow segnala il contenuto memorizzato nella cache.Ma il server è ancora inchiodato.

La risoluzione consiste nell'interrogare le intestazioni in entrata nello script del server dinamico e determinare se viene fornita un'intestazione "If-Modified-Since".Se questo è il caso, e viene stabilito che il contenuto non è cambiato, viene restituita una risposta HTTP_NOT_MODIFIED (304).

Questo non è ottimale (preferirei che Firefox non effettuasse affatto le richieste), ma dimezza il tempo di caricamento della pagina e riduce notevolmente la larghezza di banda.Dato il modo in cui Firefox funziona durante la ricarica, questa sembra la soluzione migliore.

Altri commenti:Il punto di Jim Ferran sull'allontanarsi dalla pagina e ritornare è valido: la cache viene sempre utilizzata e non ci sono richieste in uscita (+1 a Jim).Inoltre, i contenuti aggiunti dinamicamente (ad es.Anche le chiamate AJAX dopo il caricamento iniziale) sembrano utilizzare la cache.

Spero che questo aiuti qualcuno oltre a me :)

Answer 2

La richiesta originale ha

Cache-Control: no-cache

che indica a tutte le cache HTTP intermedie (inclusa quella di Firefox) che non si desidera utilizzare una risposta memorizzata nella cache, si desidera ottenere la risposta dal server Web di origine stesso.

La risposta dice:

Cache-Control: public, max-age=31536000

che dice a tutti che per quanto riguarda il server di origine, la risposta Maggio essere memorizzato nella cache.Il server sembra essere configurato per consentire la memorizzazione nella cache dell'immagine PNG: HTTP 1.1 (sezione 14.21) dice:

Nota:Se una risposta include un campo di controllo della cache con la direttiva massima-età (vedere la sezione 14.9.3), tale direttiva sovrascrive il campo scade.

La tua seconda richiesta dice:

Cache-Control: max-age=0

che indica a tutte le cache HTTP intermedie che non accetterai alcuna risposta memorizzata nella cache più vecchia di 0 secondi.

Una cosa a cui prestare attenzione:se premi il pulsante Ricarica in Firefox, ti viene chiesto di ricaricare dal server web di origine.Per testare la memorizzazione nella cache dell'immagine, allontanati dalla pagina e torna indietro oppure aprila in una nuova scheda.Non sono sicuro del motivo per cui hai visto no-cache la prima volta e max-age=0 la seconda.

A proposito, mi piace il plug-in FireBug per Firefox.Puoi dare un'occhiata alle intestazioni di richiesta e risposta e ogni sorta di altre cose utili.

Answer 3

Sembra che sia stato risolto:

• Rimosso il proxy tramite intestazione
• Aggiunta un'intestazione Ultima modifica
• Aggiunta una data di scadenza lontana nel futuro

Firebug mostra ancora 200 risposte dal server di origine, tuttavia, YSlow riconosce le immagini come memorizzate nella cache.Secondo YSlow, la dimensione totale del download dell'immagine quando è fresca è maggiore di 500K;con la cache attivata, mostra una dimensione di download di 0K.

Ecco l'intestazione della risposta dal server Origin che fa il trucco:

Date: Tue, 24 Nov 2009 08:54:24 GMT
Server: Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
Last-Modified: Sun, 22 Nov 2009 07:28:25 GMT
Expires: Tue, 30 Nov 2010 19:00:25 GMT
Content-Length: 10883
Content-Type: image/jpeg
Keep-Alive: timeout=15, max=89
Connection: Keep-Alive

Dato il modo in cui richiedo le immagini, non dovrebbe importare se queste date sono statiche;la mia app conosce l'ultima modifica prima di richiedere l'immagine e la aggiunge all'URL della richiesta sul lato client per creare un URL univoco per ciascuna versione dell'immagine, ad es. http://myserver.com/img/125.jpg?20091122 (le informazioni provengono da un feed AJAX JSON).Potrei, ad esempio, impostare la data dell'ultima modifica il 1° gennaio 2000 e la data di scadenza nell'anno 2050.

Se YSlow è corretto - e il test delle prestazioni implica che lo sia - allora FireBug dovrebbe effettivamente segnalare questi riscontri nella cache locale invece di una risposta 200.