Der cache-controlHeader ist der primäre Mechanismus für einen HTTP-Server, um einem Caching-Proxy die "Aktualität" einer Antwort mitzuteilen. (dh wie / ob lange, um die Antwort im Cache zu speichern)
In einigen Situationen sind cache-controlRichtlinien unzureichend. Hier wird eine Diskussion der HTTP-Arbeitsgruppe archiviert , die eine Seite beschreibt, die sich nur mit der Sprache ändert. Dies ist nicht der richtige Anwendungsfall für den variierenden Header, aber der Kontext ist für unsere Diskussion wertvoll. (Obwohl ich glaube, dass der Vary-Header das Problem in diesem Fall lösen würde, gibt es einen besseren Weg.) Von dieser Seite:
Vary Dies gilt ausschließlich für Fälle, in denen es für einen Proxy hoffnungslos oder übermäßig kompliziert ist, das zu replizieren, was der Server tun würde.
Ein erfundenes Beispiel:
Ihr HTTP-Server verfügt über eine große Zielseite. Sie haben zwei leicht unterschiedliche Seiten mit derselben URL, je nachdem, ob der Benutzer zuvor dort war. Sie unterscheiden zwischen Anfragen und der "Besuchsanzahl" eines Benutzers basierend auf Cookies. Da die Zielseite Ihres Servers jedoch so groß ist, möchten Sie, dass zwischengeschaltete Proxys die Antwort nach Möglichkeit zwischenspeichern.
Die URL-, Last-Modified- und Cache-Control-Header reichen nicht aus, um einem Caching-Proxy diesen Einblick zu gewähren. Wenn Sie jedoch hinzufügen Vary: Cookie, fügt die Cache-Engine den Cookie-Header zu ihren Caching-Entscheidungen hinzu.
Schließlich habe ich für kleine, dynamische Websites immer das Einfache Cache-Control: no-cache, no-storeund Pragma: no-cacheAusreichende gefunden.
Bearbeiten - um Ihre Frage genauer zu beantworten: Der HTTP-Anforderungsheader 'Akzeptieren' definiert die Inhaltstypen, die ein Client verarbeiten kann. Wenn Sie zwei Kopien desselben Inhalts unter derselben URL haben, die sich nur im Inhaltstyp unterscheiden, kann die Verwendung Vary: Acceptangemessen sein.
Update 11. September 12:
Ich füge ein paar Links hinzu, die in den Kommentaren erschienen sind, seit dieser Kommentar ursprünglich gepostet wurde. Sie sind beide hervorragende Ressourcen für Beispiele (und Probleme) aus der Praxis mit Vary: Accept; Wenn Sie diese Antwort lesen, müssen Sie auch diese Links lesen.
Das erste, von EricLaw, über das Verhalten von Internet Explorer mit dem Vary-Header und einige der Herausforderungen, die es Entwicklern stellt: Vary-Header verhindert das Caching im IE . Kurz gesagt, IE (vor IE9) speichert keine Inhalte zwischen, die den Vary-Header verwenden, da der Anforderungscache keine HTTP-Anforderungsheader enthält. EricLaw (Eric Lawrence in der realen Welt) ist Programmmanager im IE-Team.
Die zweite stammt von Eran Medan und ist eine laufende Diskussion über unerwartetes Verhalten im Zusammenhang mit Vary in Chrome: Backing behandelt Vary-Header nicht richtig . Es hängt mit dem Verhalten des IE zusammen, außer dass die Chrome-Entwickler einen anderen Ansatz gewählt haben - obwohl es keine bewusste Entscheidung zu sein scheint.