Les directives de contrôle du cache du navigateur

Les caches se comportent en fonction des directives de contrôle de cache fournies avec les données. Elles font partie des entêtes HTTP. Elles indiquent si un objet peut être mis en cache ou non, comment il a été validé contre le serveur et quelle est sa durée de vie. Le but de cet article est de donner quelques instructions pour utiliser les directives de contrôle de cache.

Le champ HTTP "Expire"

La date d'expiration est indiquée par les champs d'entête HTTP Expires. il indique la date et l'heure après lesquelles l'objet est considéré comme périmé. La date est une date HTTP absolue comme spécifié par la RFC 1123. Il faut aussi se rappeler que dans le cadre du protocole HTTP, toutes les dates sont GMT.

Expire: Tue., 02 déc. 2017 16:00:00 GMT

Le problème de la date d'expiration est que tous les serveurs, proxies et navigateurs doivent convenir d'une date et d'une heure commune : l'heure GMT. Cela n'arrive jamais puisque la plupart des navigateurs utilisent l'heure locale. Heureusement, il existe une solution, le calcul de durée de vie sans horloge (clockless) basé sur le champ d'entête HTTP Age.

La directive "max-age"

Cette directive indique la durée de fraîcheur de l'objet. Les objets sont donc considérés comme frais au cours de la période indiquée et seront donc utilisés par le navigateur sans validation et donc sans qu'aucune requête ne soit envoyée au serveur HTTP. La durée de vie est calculée en fonction de la valeur de l'entête HTTP Age. Elle est exprimée en secondes.

Par exemple, la directive suivante indique que l'objet sera frais pour un jour.

Cache-Control: max-age=86400

La directive "public"

La directive public indique qu'un cache public partagé cache l'objet même s'il ne peut normalement pas être mis en cache ou ne peut être mis en cache que dans un cache non partagé, principalement lorsque le champ d'entête HTTP Authorization est présent.

Étant donné que les heuristiques de proxy étendent cette condition à la présence de cookies de session ou de paramètres de chaîne de requête, il est important d'ajouter cette directive lorsque des cookies sont ajoutés à l'entête HTTP de la réponse.

La directive "private"

Cette directive indique que l'objet envoyé par le serveur HTTP est destiné à un seul utilisateur. C'est le cas de toute donnée générée dynamiquement et attachée à une session. Par conséquent, une telle donnée ne doit pas être mise en cache par un cache public.

La directive "no-cache"

Malgré son nom, la directive n'indique pas que l'objet ne doit pas être mis en cache. Lorsqu'il est présent dans l'entête HTTP de réponse, il indique que l'objet doit être validé par rapport au serveur d'origine.

La directive "must-revalidate"

Cette directive indique aux navigateurs que la donnée doit être revalidée à chaque utilisation. Cela assure que la donnée affichée est toujours à jour. Elle est plus précise que la directive no-cache.

La directive "no-store"

Cette directive indique qu'aucune partie du message de réponse, c'est-à-dire ni l'objet ni l'entête HTTP, ne doit être stockée dans un stockage persistant. Cette directive s'applique aux caches partagés et non partagés, y compris le cache du navigateur.

L'objectif initial de cette directive était de protéger la vie privée. Toutefois, étant donné que le cache peut être compromis ou peut ne pas respecter cette directive, la confidentialité ne devrait pas dépendre d'une telle directive. Toutefois, il s'agit toujours d'un bon moyen d'empêcher les navigateurs de réutiliser un objet mis en cache et d'appliquer des réponses dynamiques à mettre à jour.

Comment faire

UBfast permet de modifier, ajouter ou supprimer toutes les directives de cache pour un objet ou un ensemble d'objets définis par leurs URL. Par exemple on peut indiquer des directives de cache pour toutes les images contenues dans /images ou pour une image particulière comme :/images/photos/arbre.jpg.