81 votes

Idéal HTTP cache-têtes de contrôle pour les différents types de ressources

Je veux trouver un ensemble minimal d'en-têtes, que le travail avec "tous" les caches et les navigateurs (également lors de l'utilisation de HTTPS!)

Sur mon site web, je vais avoir trois types de ressources:

(1) Jamais mis en cache (public / l'égalité pour tous les utilisateurs)

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

  • Ces fichiers sont automatiquement attribué un nouveau nom, quand ils changent de contenu (basé sur le MD5).

  • Ils doivent se cache autant que possible, même lors de l'utilisation de HTTPS (donc, je suppose, je devrais ensemble Cache-Control: public, en particulier pour Firefox?)

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

(2) Modification de l'occasion (public / l'égalité pour tous les utilisateurs)

Exemples: index.html, mymodule.nocache.js

  • Ces fichiers d'en modifier le contenu sans changer l'URL, lorsqu'une nouvelle version du site est déployé.

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

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

Exemple: réponses JSON

  • Ces ressources ne doivent jamais être mis en cache pas cryptées sur le disque sous aucun prétexte. (Sauf peut-être je vais avoir quelques demandes spécifiques qui pourraient être mis en cache.)

J'ai une idée générale sur les dont les en-têtes je serais probablement utiliser pour chaque type, mais il y a toujours quelque chose que j'ai peut-être manquant.

89voto

Gumbo Points 279147

Je serais probablement utiliser ces paramètres:

  1. Cache-Control: max-age=31556926 – Représentations peuvent être mis en cache par un cache. La représentation en mémoire cache est d'être considérés comme des frais pour 1 an:

    Pour marquer une réponse comme "n'expire jamais," un serveur d'origine envoie un Expire date d'environ un an à partir du moment où la réponse est envoyés. HTTP/1.1, les serveurs ne DOIVENT PAS envoyer de l'Expiration des dates plus d'un année dans le futur.

  2. Cache-Control: no-cache – Les représentations sont autorisés à être mis en cache par un cache. Mais les caches doivent soumettre la demande au serveur d'origine pour validation avant de libérer une copie mise en cache.
  3. Cache-Control: no-store – Les Caches doivent pas mettre en cache la représentation dans n'importe quelle condition.

Voir la Marque de Nottingham, la mise en Cache Tutoriel pour plus d'informations.

-2voto

user360112 Points 259

Cas de un et deux sont en fait le même scénario. Vous devez définir Cache-Control: public puis de générer une URL avec inclut le numéro de version / version du site, de sorte que vous avez immuable des ressources qui pourraient durer éternellement. Vous voulez aussi de définir l' Expires d'en-tête d'un an ou plus dans l'avenir, de sorte que le client n'aura pas besoin d'émettre une actualisation de contrôle.

Pour le cas 3, on peut tout de suite pour un maximum de flexibilité:

"Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X