L'en- cache-control
tête est le mécanisme principal d'un serveur HTTP pour indiquer à un proxy de mise en cache la "fraîcheur" d'une réponse. (c'est-à-dire, combien / si longtemps pour stocker la réponse dans le cache)
Dans certaines situations, les cache-control
directives sont insuffisantes. Une discussion du groupe de travail HTTP est archivée ici, décrivant une page qui change uniquement avec la langue. Ce n'est pas le cas d'utilisation correct pour l'en-tête de variation, mais le contexte est précieux pour notre discussion. (Bien que je pense que l'en-tête Vary résoudrait le problème dans ce cas, il existe un meilleur moyen.) À partir de cette page:
Vary
est strictement pour les cas où il est désespéré ou excessivement compliqué pour un proxy de répliquer ce que le serveur ferait.
Un exemple artificiel:
Votre serveur HTTP a une grande page de destination. Vous avez deux pages légèrement différentes avec la même URL, selon que l'utilisateur y est déjà allé auparavant. Vous faites la distinction entre les demandes et le «nombre de visites» d'un utilisateur sur la base des cookies. Mais - puisque la page de destination de votre serveur est si grande, vous voulez que les proxys intermédiaires mettent en cache la réponse si possible.
Les en-têtes URL, Last-Modified et Cache-Control sont insuffisants pour donner ces informations à un proxy de mise en cache, mais si vous ajoutez Vary: Cookie
, le moteur de cache ajoutera l'en-tête Cookie à ses décisions de mise en cache.
Enfin, pour le petit trafic, les sites Web dynamiques - j'ai toujours trouvé le simple Cache-Control: no-cache, no-store
et Pragma: no-cache
suffisant.
Edit - pour répondre plus précisément à votre question: l'en-tête de requête HTTP «Accepter» définit les types de contenu qu'un client peut traiter. Si vous disposez de deux copies du même contenu à la même URL, ne différant que par Content-Type, alors l'utilisation Vary: Accept
pourrait être appropriée.
Mise à jour du 11 septembre 12:
J'inclus quelques liens qui sont apparus dans les commentaires depuis la publication de ce commentaire. Ce sont tous deux d'excellentes ressources pour des exemples (et des problèmes) du monde réel avec Vary: Accept; Si vous lisez cette réponse, vous devez également lire ces liens.
Le premier, de l'exceptionnel EricLaw, sur le comportement d'Internet Explorer avec l'en-tête Vary et certains des défis qu'il présente aux développeurs: Vary Header empêche la mise en cache dans IE . En bref, IE (pré IE9) ne met pas en cache tout contenu qui utilise l'en-tête Vary car le cache de demande n'inclut pas les en-têtes de requête HTTP. EricLaw (Eric Lawrence dans le monde réel) est un gestionnaire de programme au sein de l'équipe IE.
Le second est d'Eran Medan, et est une discussion en cours sur le comportement inattendu lié à Vary dans Chrome: Backing ne gère pas correctement l'en-tête Vary . C'est lié au comportement d'IE, sauf que les développeurs de Chrome ont adopté une approche différente - bien que cela ne semble pas avoir été un choix délibéré.