Votre page peut-elle être mise en cache par le navigateur ? voyons ce qu’il en est en théorie avec HTTP 1.1 (en pratique le navigateur fera toujours ce qu’il veut, et il y a plus de couples navigateur/configuration que vous ne l’imaginez, donc n’ayez aucune certitude).
Les absolus
Quoi que vous disiez, quoi que vous fassiez, si le serveur vous a répondu avec un code d’erreur 400, le navigateur devrait mettre en cache se résultat et ne pas refaire la même requête. C’est plutôt logique pour une requête que le serveur a considéré comme invalide.
Quoi que vous disiez, quoi que vous fassiez, si le code de retour était 303 ou 307, le navigateur ne devrait pas mettre en cache ce résultat. La redirection est temporaire, marquée comme telle, mettre en cache du temporaire c’est faire du permanent, donc contredire la réponse.
L’heuristique
S’il s’agit d’une requête de type GET avec un code de retour 200, 203, 206, 300, 301 ou 410, alors le navigateur ou le proxy sont encouragés à mettre en cache suivant leurs propres heuristiques. Le plus souvent la page HTML elle-même n’est pas mise en cache par défaut, mais les composants référencés par cette page sont mis en cache pour la durée de la session.
Il est à noter que la spécification HTTP 1.1 prévoit la fonctionnalité de retour arrière des navigateurs et incite le navigateur à réutiliser la page précédente sans la réactualiser, quand bien même elle aurait expiré. Le visiteur l’a déjà vu, il s’agit de lui représenter là où il était avant, pas de revenir sur la page actualisée.
L’invalidation
Quand le serveur répond à une requête POST, les versions en cache de cette URI ou de celle dans les entêtes Location ou Content-Location doivent être effacés. Ceci implique immédiatement que par défaut une requête POST ne sera pas mise en cache.
La spécification HTTP 1.1 va même un peu plus loin en prenant en compte l’usage des paramètres de requêtes dans les URI. Certains utilisent ainsi des paramètres en GET pour réaliser des actions qui devraient être faites en POST (puisque provocant un changement dans l’entité résultat). Pour y palier, HTTP 1.1 demande à ce que ces requêtes (contenant un point d’interrogation dans le chemin) ne soient pas mises en cache quand bien même elles seraient faites avec le verbe GET.
Petite note : Si vous renvoyez un document avec une entête Date inférieure à celle qu’avait eu le navigateur la dernière fois, cette réponse ne devrait être pas mise en cache.
La déclaration explicite
Maintenant, hors les premiers cas absolus, les entêtes explicites ont priorité. Une entête Cache-Control à public, private, ou no-cache change le comportement par défaut. Un max-age ou Expires impose un cache et un must-revalidate impose une revalidation, même si ces règles contredisent le comportement par défaut pour la ressource en question.
Enfin, les caches sont toujours dépendants de l’entête Vary, qui permet de restreindre le cache à un navigateur, ou des visteurs avec un certain cookie, etc.
Justement, une petite question sur Vary, j’utilise :
Vary: Accept,Cookie,Accept-Encoding,User-Agent
Du coup, je m’attends à ce que lorsqu’un visiteur revisite la page avec un nouveau cookie (celui de session quand l’utilisateur s’est connecté), on ne lui présente pas la page qui est dans son cache, ni celui du proxy. Or, ce n’est pas toujours le cas.
Tu as déjà rencontré des problèmes de ce type ?
Je n’ai pas fait de test ni d’étude sur ce point là, il est possible que le navigateur considère que son cache à lui est toujours valide par rapport à ce filtre, je ne sais pas. Tu as un test en ligne pour pouvoir regarder ?
Re,
Oui, http://www.elitwork.com .
Dslé pour le délai, mais j’avais pas souscrit aux alertes mail du blog.
Pour ce qui est de Vary, j’avais lu que c’était une mauvaise pratique d’utiliser autre chose que « Accept-Encoding » (et peut-être aussi « Accept »). Notamment, utiliser « User-Agent » peut faire que la page soit cachée autant de fois qu’il y a de navigateurs… ce qui veut dire, aujourd’hui, avec la multiplicité des navigateurs et des versions, qu’elle n’est pas tant cachée que ça, alors qu’en réalité, elle ne varie pas selon le navigateur.
Seul l’encoding pouvait varier jadis en raison de bugs de navigateurs vénérables, mais aujourd’hui, je pense que ce n’est plus à faire.