web-dev-qa-db-fra.com

Comment savoir si un XMLHTTPRequest a atteint le cache du navigateur

S'il est possible de dire (dans l'exécution javascript) si un GET XMLHTTPRequest a atteint le cache du navigateur au lieu d'obtenir sa réponse du serveur?

javascriptxmlhttprequestbrowser-cache
28
rjkaplan

À partir de la spécification XMLHttpRequest :

Pour les réponses 304 non modifiées résultant d'une demande conditionnelle générée par l'agent utilisateur, l'agent utilisateur doit agir comme si le serveur avait donné une réponse 200 OK avec le contenu approprié.

En d'autres termes, le navigateur donnera toujours le code d'état 200 OK, même pour les demandes qui atteignent le cache du navigateur.

Cependant, la spécification dit également:

L'agent utilisateur doit autoriser les en-têtes de demande d'auteur à remplacer la validation automatique du cache (par exemple, If-None-Match ou If-Modified-Since), auquel cas 304 réponses non modifiées doivent être transmises.

Il existe donc une solution pour rendre les réponses 304 non modifiées visibles à votre code JavaScript.

19
Feross

Lorsque vous faites une demande ajax, vous obtenez le code de réponse

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

l'état 200 signifie que vous obtenez une nouvelle copie des données:

La demande a abouti. Les informations renvoyées avec la réponse dépendent de la méthode utilisée dans la demande -

l'état 304 signifie que les données n'ont pas changé et vous les obtiendrez du cache du navigateur:

Si le client a effectué une requête GET conditionnelle et que l'accès est autorisé, mais que le document n'a pas été modifié, le serveur DEVRAIT répondre avec ce code d'état.

En savoir plus sur le code d'état

Mise à jour:
Vous pouvez ajouter un cache cache à votre URL pour garantir que vous frappez toujours le serveur:

var ajaxUrl = "/path?cache="+(Math.random()*1000000);
3
Ibu

Cette réponse est basée sur l'hypothèse que vous entendez uniquement le cache du navigateur, sans aucun 304 (modification depuis, etag, etc.).

Vérifiez combien de temps la demande a pris - si elle a été résolue à partir du cache, cela devrait prendre près de 0 ms.

1
Sean Kinsey

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

Pour les réponses 304 non modifiées résultant d'une demande conditionnelle générée par l'agent utilisateur, l'agent utilisateur doit agir comme si le serveur avait donné une réponse 200 OK avec le contenu approprié. L'agent utilisateur doit autoriser les en-têtes de demande d'auteur à remplacer la validation automatique du cache (par exemple, If-None-Match ou If-Modified-Since), auquel cas 304 réponses non modifiées doivent être transmises. [HTTP]

Je trouve cela plutôt vague. Mon hypothèse serait si une ressource est conditionnellement demandée, vous verriez le code de réponse 304. Mais, comme je l'ai expliqué dans un autre commentaire (source: https://developers.google.com/speed/docs/best-practices/caching ), il pourrait même ne pas y avoir de demande si la dernière réponse l'en-tête http du serveur pour cette ressource avait défini Cache-Control: max-age ou Expires défini dans le futur. Dans ce cas, je ne sais pas ce qui devrait arriver.

1
JayC

Utilisez-vous le Firebug de Firefox ?

Firebug a un panneau "Net" avec une vue filtrée "XHR". Vous devriez être en mesure d'inspecter les informations du cache via la barre de phase de demande, en vérifiant l'état et/ou en cliquant sur le triangle pour inspecter les "en-têtes".

En cache ou non mis en cache

Toutes les demandes réseau ne sont pas égales - certaines d'entre elles sont chargées à partir du cache du navigateur au lieu du réseau. Firebug fournit des codes d'état pour chaque demande afin que vous puissiez analyser rapidement et voir l'efficacité avec laquelle votre site utilise le cache pour optimiser les temps de chargement des pages.

Firebug Les documents Net Panel sont ici .

Chrome/Safari/Opera ont tous des outils de débogage similaires. Je viens de trouver une bonne liste ici (la plupart devraient avoir des outils pour inspecter XHR).

ÉDITER:

Afin de me racheter quelque peu ...

Comme ibu a répondu , je commencerais également par vérifier le code d'état de la réponse.

Si vous utilisez jQuery:

statusCode (ajouté 1.5) Carte par défaut: {} Une carte de codes et fonctions HTTP numériques à appeler lorsque la réponse a le code correspondant. Par exemple, ce qui suit alertera lorsque le statut de réponse est un 404:

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

Si la demande aboutit, les fonctions de code d'état prennent les mêmes paramètres que le rappel de réussite; s'il en résulte une erreur, ils prennent les mêmes paramètres que le rappel d'erreur.

jQuery rend la vie facile. :)

0
mhulse