Caching Behavior sui principali browser

Question

Caching Behavior sui principali browser

#1 da (7 voti)

2

Prima ancora di porre la domanda - questa è una domanda difficile da inquadrare, quindi accolgo con favore le modifiche per migliorare la chiarezza.

In che modo i principali browser decidono come memorizzare le risposte in cache, in particolare se le risposte vengono recuperate tramite AJAX e non dispongono di un controllo cache esplicito o di altri intestazioni della cache?

Le applicazioni che sto testando sono entrambe abbastanza simili, in quanto utilizzano un MVC JavaScript per il rendering della pagina, la risposta alle azioni dell'utente e l'esecuzione di richieste XHR. Tutte le risposte sono in JSON, ad eccezione della pagina principale. Entrambe le applicazioni sono su HTTPS. L'applicazione 1 ha l'intestazione HSTS impostata, L'applicazione 2 non lo è.

Nessuna di queste applicazioni imposta le intestazioni di Cache-Control in modo esplicito. Tuttavia Applicazione 1 contiene non informazioni sulla cache, mentre Applicazione 2 fornisce informazioni sulla cache. L'unica distinzione importante tra i due è che gli URL di Applicazione 1 sono nel formato <URL>/#/some/action/performed mentre gli URL di Applicazione 2 sono più semplici, ovvero <URL>/someaction . Il mio argomento principale era che il browser non memorizza nella cache le risposte restituite a qualsiasi URL che contiene # in esse, perché per quanto riguarda il browser, è la stessa pagina. Tuttavia, non sono convinto con questo argomento, semplicemente perché alla fine della giornata, sono tutte le richieste XHR che vengono fatte, quindi perché il diverso comportamento tra le applicazioni?

caching web-application hsts

posta Karthik Rangarajan 10.01.2014 - 03:44

fonte

1 risposta

Leggi altre domande sui tag caching web-application hsts

Certificato digitale "Firma e impronta digitale" Le migliori pratiche di sicurezza in internet cafe

score 7 · Accepted Answer

Prima di tutto; ufficialmente tutto dopo che # non fa parte dell'URL rispetto a richieste e risposte. Non viene inviato al server e viene ignorato durante il recupero e l'impostazione delle cache. Appare nella barra degli URL, ma non fa parte del percorso specificato della risorsa.

Rispetto alla domanda su come i browser determinano se memorizzare le pagine nella cache; la risposta è, dipende". IE è un po 'famoso per la cache degli XHR anche quando l'intestazione di controllo della cache dice esplicitamente non a , motivo per cui jQuery's esiste un meccanismo di eliminazione della cache ajax . La soluzione alternativa utilizzata è di aggiungere una variabile GET con un semplice contatore monotonicamente crescente. Questo rende ogni richiesta un nuovo URL - perché /foo.php?x=123 è un URL diverso da /foo.php?x=456 - e quindi una mancanza di cache garantita.

Si noti che al contrario /foo.php#x=123 seguito da /foo.php#x=456 è un potenziale HIT della cache, poiché la risorsa in questione è solo /foo.php e #x=123 viene rimosso prima del recupero.

Per quanto riguarda lo standard, credo che se non viene specificata la cache o l'età, allora il comportamento della cache non è definito: l'autore del browser è libero di decidere da solo cosa è corretto. I diversi browser probabilmente si comportano in modo diverso. E i browser sono (beh, un browser in particolare) famoso per basare importanti decisioni comportamentali su fattori apparentemente casuali. In tal caso, prendere la decisione della cache basata sull'URL Frammento è possibile nonostante sia assurdo.

Quindi, se stai usando uno di quei browser che ti fanno ridere i tuoi compagni più attenti alla tecnica, allora aspettati di sperimentare un comportamento ingiustificatamente strano. Non cercare di spiegarlo, ti arrabbi solo.

D'altra parte, se sei lo sviluppatore dell'app, (A) imposta esplicitamente un criterio cache nelle intestazioni di risposta e (B) se hai a che fare con IE, quindi utilizza i parametri GET di busting della cache.