AccueilđŸ‡«đŸ‡·Chercher

Cache-Control

En informatique, le Cache-Control est un en-tĂȘte du protocole HTTP concernant la mĂ©moire cache. En effet la plupart des navigateurs web utilisent un espace rĂ©servĂ© sur le disque dur pour enregistrer une copie des pages qui sont visitĂ©es (souvent). Ainsi quand l'utilisateur demande une page, le navigateur affiche parfois simplement la copie qu'il avait, pour gagner du temps. Le bouton recharger (actualiser, rafraĂźchir) des navigateurs permet de la mettre Ă  jour.

Le Cache-Control peut ĂȘtre dĂ©fini soit par le serveur web, soit par un .htaccess, ou encore selon les pages web par les sites en CGI, PHP, ASP[1].

HTTP/1.0

À ce niveau du protocole, il ne permet qu'un contrîle du cache rudimentaire.

Pragma: no-cache

Permet au navigateur d'indiquer au cache de récupérer le document auprÚs du serveur d'origine plutÎt que de lui renvoyer celui qu'il conserve.

HTTP/1.1

À ce niveau du protocole, l'en-tĂȘte Cache-Control offre plus de possibilitĂ©s. Le navigateur ou le serveur peuvent donner des directives Ă  un cache.

L'en-tĂȘte Cache-Control a pour valeur une liste de directives, sĂ©parĂ©es par des virgules. La spĂ©cification HTTP/1.1 dans RFC 2616[2] dĂ©finit plusieurs valeurs pour l'en-tĂȘte Cache-Control. Certaines sont trĂšs peu utilisĂ©es.

public

La rĂ©ponse HTTP peut ĂȘtre mise en cache par n'importe quel cache. Un client ou un serveur proxy peuvent mettre en cache par exemple la rĂ©ponse. Cela permet le partage de contenu Ă  travers les utilisateurs qui utilisent le mĂȘme serveur proxy.

Par exemple, si un document est renvoyĂ© aprĂšs authentification de l'utilisateur par le serveur et que cette authentification n'est destinĂ©e qu'Ă  faire des statistiques et non un contrĂŽle d'accĂšs, le document peut ĂȘtre considĂ©rĂ© comme public.

private

Le message de rĂ©ponse est destinĂ© Ă  un client unique et ne doit pas ĂȘtre mis en cache par un cache partagĂ©. Un serveur proxy ne doit pas mettre en cache la rĂ©ponse bien qu'un client puisse le faire. Cela permet au client de tenir Ă  jour une version mise en mĂ©moire cache pendant que tous les clients qui utilisent le mĂȘme serveur proxy conservent les versions diffĂ©rentes mises en mĂ©moire cache.

no-cache

Cela vous permet de spĂ©cifier que la requĂȘte suivante pour le mĂȘme contenu devra obligatoirement ĂȘtre validĂ©e par le serveur. Ceci rend l'entrĂ©e dans le cache directement pĂ©rimĂ©e[3].

Cache-Control: no-cache

no-store

EmpĂȘche le stockage non volatil (par exemple : sur disque) de la donnĂ©e.

no-transform

La directive no-transform indique aux proxies et autres systÚmes de cache qu'ils ne doivent pas transformer le corps du message qu'ils reçoivent.

Elle est par exemple prise en compte par le proxy transparent de ByteMobile, utilisé par de nombreux opérateurs mobiles tels que SFR ou Vodafone, pour leurs accÚs 3G. Ce proxy effectue diverses modifications sur les pages web, comme l'ajout de certains headers HTTP pouvant modifier le comportement du cache du navigateur, la suppression des retours à la ligne dans le code source, ou encore l'injection d'un code JavaScript destiné à augmenter la compression des images[4].

max-age

Cette directive permet à un serveur de fixer la durée maximale de rétention. Lorsqu'elle est utilisée par un client, elle indique au(x) cache(s) la fraßcheur minimale souhaitée. Les durées sont indiquées en secondes.

Cache-Control: max-age=600

Lorsque cette directive est prĂ©sente dans la requĂȘte d'un client, le cache doit renvoyer un document qui a Ă©tĂ© produit il y a au plus 10 minutes (en-tĂȘte Date). Si le cache possĂšde une rĂ©ponse plus ancienne, il est censĂ© contacter le serveur d'origine pour obtenir une version plus rĂ©cente (s'il ne le fait pas, le cache doit obligatoirement inclure un avertissement dans la rĂ©ponse). Si cette directive apparaĂźt dans la rĂ©ponse d'un serveur, elle autorise le(s) cache(s) Ă  servir cette mĂȘme rĂ©ponse pendant 10 minutes maximum.

Dans une rĂ©ponse, la directive max-age outrepasse l'en-tĂȘte Expires.

Une valeur dĂ©finie Ă  0 indique que la cible devrait ĂȘtre rechargĂ©e Ă  chaque accĂšs. Cette notion est proche mais non Ă©quivalente Ă  la valeur no-cache qui, elle, oblige la crĂ©ation du fichier Ă  chaque accĂšs sans laisser de place au choix du navigateur.

max-stale

La directive max-stale permet à un client d'autoriser le(s) cache(s) à renvoyer une réponse périmée, tout en fixant une limite à cette péremption.

Par exemple, un client peut accepter une réponse périmée depuis une heure maximum :

Cache-Control: max-stale=3600

Si le cache possĂšde une rĂ©ponse dont la fraĂźcheur dĂ©passe les limites fixĂ©es par le serveur, il pourra quand mĂȘme la servir. À condition qu'elle soit pĂ©rimĂ©e depuis moins d'une heure. Sinon, il contacte le serveur d'origine pour obtenir une rĂ©ponse de fraĂźcheur convenable.

À la limite, indiquer une durĂ©e maximale de pĂ©remption nulle ne sert Ă  rien.

Cache-Control: max-stale=0

Car cela revient Ă  autoriser les rĂ©ponses pĂ©rimĂ©es, mais seulement si elles le sont depuis moins de zĂ©ro seconde ! Aucune rĂ©ponse ne peut correspondre Ă  ce critĂšre, donc tout se passera exactement comme si le client n'avait rien prĂ©cisĂ© dans sa requĂȘte.

min-fresh

La directive min-fresh permet à un client d'exiger une réponse fraßche qui sera valable pendant toute la valeur indiquée.

Par exemple, un client peut exiger une réponse fraßche qui sera valable pendant au moins 20 secondes :

Cache-Control: min-fresh=20

min-vers

Permet d'indiquer au cache de stocker uniquement des requĂȘtes et des rĂ©ponses avec des versions HTTP supĂ©rieures ou Ă©gales Ă  celle spĂ©cifiĂ©e.

must-revalidate

Force le cache à se reconnecter au serveur avec un If-Modified-Since et doit provoquer une erreur 504[5] si la page a disparu. Si malgré les recommandations, le cache viole cette directive, il doit obligatoirement prévenir l'utilisateur et obtenir son accord pour chaque accÚs non revalidé.

proxy-revalidate

Mécanisme similaire à "must-revalidate", mais s'applique uniquement à des caches de proxy partagés (autres que ceux utilisés par le logiciel client de l'utilisateur). Cela permet de contrÎler que l'utilisateur est bien authentifié sur le serveur.

only-if-cached

Si le client s'exĂ©cute dans un rĂ©seau Ă  faible dĂ©bit, permet de demander au cache de ne rĂ©pondre que pour des Ă©lĂ©ments prĂ©sents en local, et de retourner une erreur 504 sinon. Des requĂȘtes entre caches locaux avec un bon dĂ©bit rĂ©seau sont possibles.

Notes et références

Liens externes

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.