Vary HTTP response header determines how to match
future request headers to decide whether a cached response can be used rather than
requesting a fresh one from the origin server. It is used by the server to indicate
which headers it used when selecting a representation of a resource in a content negotiation algorithm.
|Header type||Response header|
|Forbidden header name||no|
Vary: * Vary: <header-name>, <header-name>, ...
- Each request for a URL is supposed to be treated as a unique and uncacheable
request. A better way to indicate this is to use
no-store, which is clearer to read and also signals that the object shouldn't be stored ever.
- A comma-separated list of header names to take into account when deciding whether or not a cached response can be used.
When using the
Vary: User-Agent header, caching servers should consider
the user agent when deciding whether to serve the page from cache. For example, if you
are serving different content to mobile users, it can help you to avoid that a cache may
mistakenly serve a desktop version of your site to your mobile users. It can help Google
and other search engines to discover the mobile version of a page, and might also tell
them that no Cloaking is intended.
|RFC 7231, section 7.1.4: Vary||Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content|
BCD tables only load in the browser
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.