web-dev-qa-db-fra.com

Est Chrome ignorant Cache-Control: max-age?

Contexte:

  • IIS 7
  • Application Web AspNet 3.5

Les outils de développement Chrome répertorient 98 demandes pour la page d'accueil de l'application Web (aspx + js + css + images). Dans les demandes suivantes, le code d'état est 200 pour les fichiers css/images. Aucune information de cache, le navigateur demande à chaque fois au serveur si le fichier doit être mis à jour. D'ACCORD.

Dans IIS 7 J'ai défini l'en-tête HTTP pour le contrôle du cache, défini sur 6 heures pour le dossier "ressources". Dans Chrome, en utilisant les outils de développement, je peux voir que l'en-tête est bien défini en réponse:

Cache-Control: max-age=21600

Mais je reçois toujours 98 demandes ... Je pensais que le navigateur ne devrait pas demander une ressource si sa date d'expiration n'est pas atteinte, et je m'attendais à ce que le nombre de demandes baisse ...

iisgoogle-chromecache-controlcontent-expiration
36
Francois

J? ai compris. Google Chrome ignore le Cache-Control ou Expires en-tête si vous faites une demande immédiatement après une autre demande au même URI dans le même onglet (en cliquant sur le bouton Actualiser, en appuyant sur la touche F5 touche ou en appuyant Command + R). Il a probablement un algorithme pour deviner ce que l'utilisateur veut vraiment faire.

Une façon de tester le Cache-Control l'en-tête consiste à renvoyer un document HTML avec un lien vers lui-même. Lorsque vous cliquez sur le lien, Chrome sert le document à partir du cache. Par exemple, nommez le document suivant self.html :

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Test Page</title>
</head>
<body>
    <p>
        <a href="self.html">Link to the same page.</a>
        If correctly cached, a request should not be made
        when clicking the link.
    </p>
</body>
</html>

Une autre option consiste à copier l'URL et à la coller dans le même onglet ou un autre onglet.

[~ # ~] mise à jour [~ # ~] : Sur un article Chrome publié le 26 janvier 2017 , c'est décrit quel était le comportement précédent et comment il change en ne faisant que revalider la ressource principale, mais pas les sous-ressources:

Les utilisateurs se rechargent généralement soit parce qu'une page est cassée, soit que le contenu semble périmé. Le comportement de rechargement existant résout généralement les pages cassées, mais le contenu périmé est traité de manière inefficace par un rechargement régulier, en particulier sur mobile. Cette fonctionnalité a été initialement conçue à une époque où les pages cassées étaient assez courantes, il était donc raisonnable de traiter les deux cas d'utilisation à la fois. Cependant, cette préoccupation d'origine est devenue beaucoup moins pertinente à mesure que la qualité des pages Web a augmenté. Pour améliorer le cas d'utilisation du contenu périmé, Chrome a désormais un comportement de rechargement simplifié pour valider uniquement la ressource principale et continuer avec un chargement de page normal. Ce nouveau comportement maximise la réutilisation des ressources mises en cache et se traduit par latence, consommation d'énergie et utilisation des données réduites.

Dans un Facebook post également publié le 26 janvier 2017 , il est mentionné qu'ils ont trouvé un morceau de code étaient Chrome invalide tout mis en cache ressources après une demande POST:

nous avons constaté que Chrome revaliderait toutes les ressources sur les pages chargées à partir d'une demande POST. L'équipe Chrome Chrome a dit nous la raison en était que POST ont tendance à être des pages qui apportent une modification - comme faire un achat ou envoyer un e-mail - et que l'utilisateur voudrait avoir le plus à jour) page de date.

Il semble que ce ne soit plus le cas.

Enfin, il est décrit que Firefox introduit Cache-Control: immutable pour arrêter complètement la revalidation des ressources:

Firefox a implémenté une proposition d'un de nos ingénieurs d'ajouter un nouvel en-tête de contrôle de cache pour certaines ressources afin d'indiquer au navigateur que cette ressource ne devrait jamais être revalidée. L'idée derrière cet en-tête est que c'est une promesse supplémentaire du développeur au navigateur que cette ressource ne changera jamais pendant sa durée de vie maximale. Firefox a choisi d'implémenter cette directive sous la forme d'un en-tête cache-control: immuable.

J'espère que cela aide à démêler les mystères du rechargement.

68
kiewic

Chrome semble ignorer votre Cache-Control paramètres si vous rechargez dans le même onglet. Si vous copiez l'URL dans un nouvel onglet et la chargez-y, Chrome respectera les balises de contrôle du cache et réutilisera le contenu du cache.

Par exemple, j'avais cette Ruby Sinatra app:

#!/usr/bin/env Ruby

require 'sinatra'

before do
  content_type :txt
end

get '/' do
  headers "Cache-Control" => "public, must-revalidate, max-age=3600",
          "Expires" => Time.at(Time.now.to_i + (60 * 60)).to_s
  "This page rendered at #{Time.now}."
end

Lorsque je l'ai rechargé en continu dans le même onglet Chrome, il afficherait la nouvelle heure.

This page rendered at 2014-10-08 13:36:46 -0400.
This page rendered at 2014-10-08 13:36:48 -0400.

Les en-têtes ressemblaient à ceci:

< HTTP/1.1 200 OK
< Content-Type: text/plain;charset=utf-8
< Cache-Control: public, must-revalidate, max-age=3600
< Expires: 2014-10-08 13:36:46 -0400
< Content-Length: 48
< X-Content-Type-Options: nosniff
< Connection: keep-alive
* Server thin is not blacklisted
< Server: thin

Cependant, accéder à la même URL, http://localhost:4567/ à partir de plusieurs nouveaux onglets recyclerait le résultat précédent du cache.

14
slm

Après avoir fait quelques tests avec Cache-Control:max-age=xxx:

  • En appuyant sur le bouton de rechargement: en-tête ignoré
  • Saisie de la même URL dans n'importe quel onglet (actuel ou non): honoré
  • Utilisation de JS (window.location.reload()): ignoré
  • L'utilisation des outils de développement (avec Désactiver le cache non sélectionné) ou incognito n'affecte pas

Ainsi, la meilleure option lors du développement est placez le curseur dans l'omnibox et appuyez sur Entrée au lieu du bouton Actualiser.

Remarque: un clic droit sur l'icône d'actualisation affichera les options d'actualisation (Normal, Hard, Empty Cache). Incroyablement, aucun de ces éléments n'affecte ces en-têtes.

13
sinuhepop

Si Chrome Les outils de développement sont ouverts (F12), Chrome désactive généralement la mise en cache).

Il est contrôlable dans les paramètres Developer Tools - l'icône Gear à droite de la barre supérieure de dev-tools.

11
user3841754

Bien que cette question soit ancienne, je voulais ajouter que si vous développez à l'aide d'un certificat auto-signé sur https et qu'il y a un problème avec le certificat, Google ne mettra pas en cache la réponse, quels que soient les en-têtes de cache que vous utilisez.

Ceci est noté dans ce rapport de bogue: https://bugs.chromium.org/p/chromium/issues/detail?id=110649

0
Beyerz