Come dire se un oggetto XMLHTTPRequest colpito la cache del browser

Se così si può dire (in un raggio di javascript esecuzione) se un XMLHTTPRequest colpito la cache del browser, invece di ottenere la risposta dal server?

InformationsquelleAutor rjkaplan | 2012-12-09

 

5 Replies
  1. 19

    Dal XMLHttpRequest spec:

    Per 304 Not Modified risposte che sono il risultato di un agente utente
    generata richiesta condizionale l’agente utente deve agire come se il server
    ha dato una risposta 200 OK con contenuti appropriati.

    In altre parole, il browser sempre di dare il codice di stato 200 OK, anche per le richieste che ha colpito la cache del browser.

    Tuttavia, la specifica dice anche:

    L’agente utente deve consentire l’autore intestazioni di richiesta di override automatica della cache
    validazione (ad esempio If-None-Match o If-Modified-Since), nel qual caso
    304 Not Modified le risposte devono essere passati.

    Così, non c’è una soluzione per rendere il 304 Not Modified risposte visibile il codice JavaScript.

  2. 3

    Quando si effettua una richiesta ajax, Si ottiene il codice di risposta

    if (request.readyState == 4) {
         if (request.status == 200) { //this number.
           ...

    stato di 200 significa che si stanno ottenendo una copia aggiornata dei dati:

    La richiesta ha avuto esito positivo. Le informazioni restituite con la risposta dipende dal metodo utilizzato nel sottoporre la richiesta –

    stato di 304 significa che i dati non è cambiato e si ottiene dalla cache del browser:

    Se il client ha effettuato una richiesta GET condizionale e l’accesso è consentito, ma il documento non è stato modificato, il server DEVE rispondere con questo codice di stato.

    Leggi di più su Codice di Stato

    Aggiornamento:

    È possibile aggiungere una cache buster per il tuo URL a garantire che si ha sempre colpito il server:

    var ajaxUrl = "/path?cache="+(Math.random()*1000000);
    • Sembra ragionevole, ma non è coerente con quello che sto vedendo. Mi sembra di essere sempre 200s nella risposta (come verificato in js e sul Chrome scheda di rete), ma la scheda di rete mi dice che la risposta è venuta dalla cache (confermata dalla risposta che essere molto più veloce rispetto a quando la scheda di rete dice che la risposta non è dalla cache del browser). FYI questi sono cross-origin richieste di caricare una pagina per origin1.com e rendere ajax richieste GET a origin2.com.
    • BTW, non so come funziona con XMLHTTPRequest, ma so che con alcune intestazioni http/valori (sembra Expires e Cache-Control: max-age secondo developers.google.com/speed/docs/best-practices/caching) c’è potrebbe anche non essere una richiesta per determinate risorse, quindi, in questo caso un codice di stato non necessariamente di senso.
    • Purtroppo, sto avendo difficoltà a trovare quello che il comportamento potrebbe essere per XMLHttpRequest in un tale scenario. Forse qualcun altro può trovare w3.org/TR/2012/WD-XMLHttpRequest-20121206
    • 304 ancora significa che sta colpendo il server. Quando il contenuto viene memorizzato nella cache in modo che il browser non deve mai fare IO di rete, si ottiene sempre 200.
  3. 1

    Da http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/

    Per 304 Not Modified risposte che sono il risultato di un agente utente
    generata richiesta condizionale l’agente utente deve agire come se il server
    ha dato una risposta 200 OK con contenuti appropriati. L’agente utente
    deve consentire l’autore intestazioni di richiesta di override automatica della cache
    validazione (ad esempio If-None-Match o If-Modified-Since), nel qual caso
    304 Not Modified le risposte devono essere passati. [HTTP]

    Trovo che questo sia piuttosto vago. La mia ipotesi sarebbe se una risorsa è condizionale richiesto, il codice di risposta 304. Ma, come ho spiegato in un altro commento (fonte: https://developers.google.com/speed/docs/best-practices/caching), ci potrebbe anche non essere una richiesta se l’ultima risposta del server intestazione http per la risorsa si era imposta Cache-Control: max-age o Expires insieme in futuro. In questo caso, non sono sicuro di ciò che dovrebbe accadere.

  4. 1

    Questa risposta si basa sul presupposto che si intende solo la cache del browser, senza 304 in atto (modified-since, etag ecc).

    Controllare per quanto tempo la richiesta ha preso – se è stato risolto dalla cache, allora si dovrebbe prendere vicino a 0ms.

  5. 0

    Usi Firefox Firebug?

    Firebug è un “Netto” del pannello con un “XHR” visualizzazione filtrata. Si dovrebbe essere in grado di controllare la cache info tramite la richiesta di fase di bar, il controllo dello stato e/o facendo clic sul triangolo a ispezionare “Intestazioni”.

    Cache o non in cache

    Non tutte le richieste di rete sono uguali, alcuni di loro vengono caricati dal
    la cache del browser invece di rete. Firebug fornisce i codici di stato
    per ogni richiesta in modo che è possibile eseguire rapidamente la scansione e vedere come effettivamente il tuo
    il sito utilizza la cache per ottimizzare i tempi di caricamento della pagina.

    Firebug Net Pannello di documenti sono qui.

    Chrome/Safari/Opera similari strumenti di debug. Appena trovato un buona lista qui (la maggior parte dovrebbe avere gli strumenti per ispezionare XHR).


    EDIT:

    Per un po ‘ di riscattare me stesso…

    Come ibu ha risposto, mi piacerebbe anche iniziare controllando il codice di stato della risposta.

    Se si utilizza jQuery:

    statusCode(aggiunto 1.5)
    Mappa Di Default: {}
    Una mappa di tipo numerico HTTP codici e le funzioni per essere chiamato quando il
    la risposta è il codice corrispondente. Per esempio, il seguente
    di avviso quando la risposta è stato un errore 404:

    $.ajax({
      statusCode: {
        404: function() {
          alert("page not found");
        }
      }
    });

    Se la richiesta ha esito positivo, il codice di stato le funzioni di prendere lo stesso
    parametri come il successo di callback; se si verifica un errore, si
    prendere gli stessi parametri come l’errore di callback.

    jQuery di sicuro non rendono la vita facile. 🙂

    • Immagino OP sta parlando di circa il controllo dall’interno di un programma JavaScript.
    • Ah, il mio errore. 🙂
    • Ho appena aggiornato il post per rendere chiaro. Grazie per la risposta, comunque!
    • Il mio male, mi hanno guardato più da vicino la vostra tag. Noob errore sul mio conto. 😉

Lascia un commento