Abilita il caching dei file css e js in Apache

Question

Utilizzando Apache 2.4 su Debian 8.2, sto cercando di abilitare il caching di tutti i file css e js. Il caching delle immagini funziona bene; cioè, il browser riceve uno stato 304, quindi non lo scarica di nuovo. Ma non riesco a far funzionare la memorizzazione nella cache di altri file.

Io uso questo all'interno di un file host virtuale:

<IfModule mod_expires.c> 
    <FilesMatch "\.(jpe?g|png|gif|js|css)$"> 
     ExpiresActive On 
     ExpiresDefault "access plus 1 week" 
    </FilesMatch> 
</IfModule> 

Il modulo expires è abilitato. Ho riavviato apache, pulito i cookie del browser, ecc. Nessun successo.

La risposta per un'immagine GIF, da strumenti per gli sviluppatori del browser:

Cache-Control:max-age=604800 
Connection:Keep-Alive 
Date:Wed, 25 Nov 2015 21:37:50 GMT 
ETag:"4174a-4e69c97fbf080" 
Expires:Wed, 02 Dec 2015 21:37:50 GMT 
Keep-Alive:timeout=5, max=100 
Server:Apache/2.4.10 (Debian) 

La risposta di un file css:

Accept-Ranges:bytes 
Cache-Control:max-age=604800 
Connection:Keep-Alive 
Content-Encoding:gzip 
Content-Length:135 
Content-Type:text/css 
Date:Wed, 25 Nov 2015 21:37:50 GMT 
ETag:"5116-525639d271c78-gzip" 
Expires:Wed, 02 Dec 2015 21:37:50 GMT 
Keep-Alive:timeout=5, max=99 
Last-Modified:Wed, 25 Nov 2015 20:50:52 GMT 
Server:Apache/2.4.10 (Debian) 
Vary:Accept-Encoding 

Sembra che il scade intestazione è impostato correttamente, ma il browser continua a richiedere il file (200 OK).

Ho provato con Chrome e Firefox.

Sommario:

1.) quando seguo i collegamenti all'interno del sito web, il browser utilizza i file memorizzati nella cache. Ma quando premo F5, scaricano nuovamente i file css e js, ma non riescono a scaricare nuovamente le immagini. Le immagini danno 304. Va bene.

2.) Quando premo Ctrl-F5, in modo naturale, tutti i file vengono scaricati di nuovo. Anche quello va bene.

3.) Quindi il problema è come abilitare il caching (proprio come le immagini) per altri file. Perché l'apache discrimina tra immagini e altri file? Non ho messo nulla di speciale per le immagini nei file di configurazione.

D: Come abilitare correttamente il caching dei file css e js?

Un altro Q: c'è una speciale intestazione http che dice al browser di non richiedere mai il file. Il motivo è, inviando anche una richiesta per verificare se il file è modificato richiede 100-200 ms, che è troppo. Sono sicuro che i file non saranno modificati. E se vengono modificati, posso facilmente inserire una stringa di versione alla fine del file css, come myFile.css? V = 1.1 Quindi spero che ci dovrebbe essere un modo per interrompere completamente l'invio delle richieste.

risolto

In primo luogo, c'è un bug in Apache come accennato nella risposta qui di seguito.

In secondo luogo, c'era un equivoco da parte mia. Immagino che questo sia il modo in cui funzionano i browser moderni:

1.) Segui i collegamenti all'interno di un sito Web: non viene inviata alcuna richiesta, anche per verificare se il file è stato modificato.

2.) F5: invia una richiesta. Se il file non viene modificato, il server risponde 304.

3.) Ctrl + F5: download completo.

Il comportamento su F5 non ha senso per me. Comunque.

Nel caso in cui nessuno ha bisogno, qui è una soluzione di lavoro che ho messo in file di host virtuale:

RequestHeader edit "If-None-Match" "^\"(.*)-gzip\"$" "\"$1\"" 
Header edit "ETag" "^\"(.*[^g][^z][^i][^p])\"$" "\"$1-gzip\"" 

LoadModule expires_module /usr/lib/apache2/modules/mod_expires.so 
ExpiresActive On 

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$"> 
    ExpiresDefault "access plus 4 weeks" 
</FilesMatch> 

Answer 1

Spegnere Etags, essi non gioca bene in Apache quando gzip è per 304S.

vedere qui: Apache is not sending 304 response (if mod_deflate and AddOutputFilterByType is enabled)

Come le immagini sono già compressi non sono in genere compressi con gzip e quindi perché funzionano.

Gli ETAG non sono utili a mio avviso nella loro attuale implementazione (vedere il mio blog here per una discussione più approfondita sul perché) quindi, accoppiato con bug di cui sopra, li spengo.

Per la seconda domanda è sufficiente impostare una lunga scadenza.

Come discusso nei commenti qui sotto ci sono tre scenari:

1. normale navigazione - in cui il caching deve essere utilizzato e 304S usato solo se la cache è ancora valida dopo la scadenza (nel qual caso è impostato su valida ancora per la stessa scadenza).

2. F5 o pulsante Aggiorna. Si tratta di un'azione esplicita da parte dell'utente per confermare la pagina e tutte le sue risorse sono ancora valide in modo che vengano verificate due volte (anche quelle ancora in cache e ancora valide in base all'intestazione di scadenza) e 304 inviate quando non sono state modificate. Non significa "solo scaricare di nuovo tutto ciò che è scaduto, ma lasciare gli elementi memorizzati nella cache in quanto sono ancora validi" come pensi che dovrebbe. Personalmente ritengo che l'attuale implementazione utilizzata dai browser abbia senso e il tuo metodo sarebbe fonte di confusione per gli utenti finali. Mentre alcuni siti possono disporre di risorse della versione come immagini, css e JavaScript, per cui la ricontrollatura è una perdita di tempo, non tutti i siti di questo tipo lo fanno.

3. Ctrl + F5. Questo è un aggiornamento di forza. Significa "Ignora la cache e scarica tutto". È raramente necessario tranne che per gli sviluppatori che modificano i file richiesti sui server di sviluppo.

Spero che tutto abbia un senso.

Modifica 12 Maggio 2016: Sembra che Firefox sta portando nella funzionalità si vuole realmente: https://bitsup.blogspot.ie/2016/05/cache-control-immutable.html?m=1