La nostra implementazione corrente utilizza un approccio di busting della cache di home build: Abbiamo un file di mapping che contiene hash dei nostri file javascript (questa mappatura viene creata all'avvio dell'applicazione). I valori in questo file vengono quindi utilizzati nei nostri modelli per generare un tag script che include un parametro GET per busting della cache, ovvero <script src="/static/js/somefile?v=adg34d>Posso fare affidamento su ETags per il controllo della cache
Attualmente sto convertendo la nostra intera pagina per utilizzare RequireJS e vorrei liberarmi di questi parametri di busting della cache dal momento che sarebbero difficili da implementare. I nostri server HTTP sono configurati per aggiungere un'intestazione corretta Last-Modified e ETag a ciascuna risorsa risorsa che servono. Se guardo la console web di Chrome, posso vedere che anche il browser lo utilizza e ottiene uno 304 corretto. Mentre mi fido di Chrome per farlo correttamente ci sono ovviamente altri browser.
La domanda è: Se io uso solo Last-Modified e ETag intestazioni posso contare sul browser per farlo bene o ne ho veramente bisogno un parametro di busting della cache?
Ho solo bisogno di sostenere:
- Opera
- Firefox
- Chrome
- IE> = 8
- Safari> = 5
Con il tuo approccio originario, l'url è diverso, e potresti nasconderlo indefinitamente sapendo che se fosse cambiato l'url sarebbe cambiato, con etags dovrai sempre fare un controllo 304 per verificare. Se il tuo metodo attuale usa 304 anche nulla cambierà, e allora sì usando ETags funziona come descritto, tuttavia, poiché le richieste sono asincrone il browser si risolverà a cache spesso. Alla fine si aggiornerà (come riaprire il browser) ma un semplice F5 non funzionerà sempre. –