HTTP
Mise en cache des réponses HTTP
Recherche…
Remarques
Les réponses sont mises en cache séparément pour chaque URL et chaque méthode HTTP.
La mise en cache HTTP est définie dans la RFC 7234 .
Glossaire
- fresh - état d'une réponse mise en cache, qui n'a pas encore expiré. En règle générale, une nouvelle réponse peut satisfaire des demandes sans qu'il soit nécessaire de contacter le serveur dont la réponse provient.
- stale - état d'une réponse mise en cache, qui a dépassé sa date d'expiration. En règle générale, les réponses obsolètes ne peuvent pas être utilisées pour satisfaire une demande sans vérifier auprès du serveur si elle est toujours valide.
- satisfaire - réponse en cache satisfait une demande lorsque toutes les conditions de la demande correspondent à la réponse mise en cache, par exemple , ils ont la même méthode HTTP et URL, la réponse est frais ou la demande permet des réponses périmées, têtes de requête correspondent en- têtes listés en réponse de
Vary- tête, etc. . - revalidation - vérifie si une réponse en cache est fraîche. Cela se fait généralement avec une requête conditionnelle contenant
If-Modified-SinceouIf-None-Matchet le statut de réponse304. - cache privé - cache pour un seul utilisateur, par exemple dans un navigateur Web. Les caches privées peuvent stocker des réponses personnalisées.
- cache public - cache partagé entre de nombreux utilisateurs, par exemple sur un serveur proxy. Un tel cache peut envoyer la même réponse à plusieurs utilisateurs.
Réponse cache pour tout le monde pendant 1 an
Cache-Control: public, max-age=31536000
public signifie que la réponse est la même pour tous les utilisateurs (elle ne contient aucune information personnalisée). max-age est en secondes à partir de maintenant. 31536000 = 60 * 60 * 24 * 365.
Ceci est recommandé pour les actifs statiques qui ne sont jamais destinés à changer.
Cache personnalisé réponse pendant 1 minute
Cache-Control: private, max-age=60
private spécifie que la réponse ne peut être mise en cache que pour l'utilisateur qui a demandé la ressource et ne peut pas être réutilisée lorsque d'autres utilisateurs demandent la même ressource. Ceci est approprié pour les réponses qui dépendent des cookies.
Arrêtez l'utilisation des ressources mises en cache sans vérifier d'abord avec le serveur
Cache-Control: no-cache
Le client se comportera comme si la réponse n'était pas mise en cache. Ceci est approprié pour les ressources qui peuvent changer de manière imprévisible à tout moment et que les utilisateurs doivent toujours voir dans la dernière version.
Les réponses avec no-cache seront plus lentes (latence élevée) en raison de la nécessité de contacter le serveur chaque fois qu'elles sont utilisées.
Cependant, pour économiser de la bande passante, les clients peuvent toujours stocker ces réponses. Les réponses avec no-cache ne seront pas utilisées pour satisfaire les demandes sans contacter le serveur à chaque fois pour vérifier si la réponse mise en cache peut être réutilisée.
Demander des réponses à ne pas stocker du tout
Cache-control: no-store
Indique aux clients de ne pas mettre la réponse en cache de quelque manière que ce soit et de l’oublier le plus rapidement possible.
Cette directive a été conçue à l'origine pour les données sensibles (aujourd'hui, HTTPS devrait être utilisé à la place), mais peut être utilisé pour éviter de polluer les caches avec des réponses qui ne peuvent pas être réutilisées.
Il convient uniquement dans des cas spécifiques où les données de réponse sont toujours différentes, par exemple un point de terminaison d'API renvoyant un grand nombre aléatoire. Sinon, no-cache et la revalidation peuvent être utilisés pour avoir un comportement de réponse "irréversible", tout en pouvant économiser de la bande passante.
En-têtes obsolètes, redondants et non standard
Expires- spécifie la date à laquelle la ressource devient obsolète. Il repose sur des serveurs et des clients disposant d’horloges précises et de fuseaux horaires appropriés.Cache-control: max-agea priorité surExpireset est généralement plus fiable.post-checkdirectivespost-checketpre-checksont des extensions non standard d'Internet Explorer qui permettent d'utiliser des réponses obsolètes. L'alternative standard eststale-while-revalidate.Pragma: no-cache- obsolète en 1999 .Cache-controldoit être utilisé à la place.
Modification des ressources en cache
La méthode la plus simple pour contourner le cache consiste à modifier l'URL. Ceci est utilisé comme une bonne pratique lorsque l’URL contient une version ou une somme de contrôle de la ressource, par exemple
http://example.com/image.png?version=1
http://example.com/image.png?version=2
Ces deux URL seront mises en cache séparément, donc même si …?version=1 était mis en cache pour toujours , une nouvelle copie pourrait être immédiatement récupérée sous la forme …?version=2 .
Veuillez ne pas utiliser d'URL aléatoires pour contourner les caches. Utilisez Cache-control: no-cache ou Cache-control: no-store place. Si des réponses avec des URL aléatoires sont envoyées sans la directive no-store , elles seront stockées inutilement dans des caches et expulseront des réponses plus utiles du cache, dégradant les performances de la totalité du cache.