web-dev-qa-db-fra.com

En-têtes de contrôle de cache HTTP idéaux pour différents types de ressources

Je veux trouver un ensemble minimal d'en-têtes, qui fonctionnent avec "tous" les caches et les navigateurs (également lorsque vous utilisez [~ # ~] https [~ # ~] !)

Sur mon site Web, j'aurai trois types de ressources:

(1) Forever cacheable (public/égal pour tous les utilisateurs)

Exemple: 0A470E87CC58EE133616F402B5DDFE1C.cache.html ( généré automatiquement par GWT )

  • Ces fichiers reçoivent automatiquement un nouveau nom lorsqu'ils changent de contenu (en fonction du MD5).

  • Ils devraient être mis en cache autant que possible, même lorsque vous utilisez HTTPS (donc je suppose que je devrais définir Cache-Control: public, surtout pour Firefox?)

  • Ils ne devraient pas obliger le client à effectuer un aller-retour vers le serveur pour valider, si le contenu a changé.

(2) Changement occasionnel (public/égal pour tous les utilisateurs)

Exemples: index.html, mymodule.nocache.js

  • Ces fichiers modifient leur contenu sans changer l'URL, lorsqu'une nouvelle version du site est déployée.

  • Ils peuvent être mis en cache, mais ont probablement besoin d'un aller-retour pour être revalidés à chaque fois.

(3) Individuel pour chaque demande (privé/spécifique à l'utilisateur)

Exemple: réponses JSON

  • Ces ressources ne doivent en aucun cas être mises en cache non chiffrées sur le disque. (Sauf peut-être que j'aurai quelques demandes spécifiques qui pourraient être mises en cache.)

J'ai une idée générale sur les en-têtes que j'utiliserais probablement pour chaque type, mais il y a toujours quelque chose qui pourrait me manquer.

httpcachinghttpshttp-headers
81
Chris Lercher

J'utiliserais probablement ces paramètres:

  1. Cache-Control: max-age=31556926 - Les représentations peuvent être mises en cache par n'importe quel cache. La représentation en cache doit être considérée comme fraîche pendant 1 an:

    Pour marquer une réponse comme "n'expire jamais", un serveur Origin envoie une date Expire environ un an après l'envoi de la réponse. Les serveurs HTTP/1.1 NE DEVRAIENT PAS envoyer dates d'expiration plus d'un an à l'avenir.

  2. Cache-Control: no-cache - Les représentations peuvent être mises en cache par n'importe quel cache. Mais les caches doivent soumettre la demande au serveur Origin pour validation avant de libérer une copie mise en cache.
  3. Cache-Control: no-store - Les caches ne doivent mettre en cache la représentation sous aucune condition.

Voir Mark Nottingham’s Caching Tutorial pour plus d’informations.

89
Gumbo