What is the function of HTTP Vary Header?
HTTP Vary header is the primary mechanism for returning an HTTP response of the server to notify intermediate caches (like proxy servers) that the website content varies depending on the specifications of the requesting web client. In other words – it warns them to pay attention which content version is cached and which is served to different web users.
The origin server must use Vary Header to inform all intermediate caching services that there are different content versions.
You can set any HTTP header as value of the Vary header, that is used by website to detect the appropriate content to serve, for example Vary: User-Agent, Accept-Encoding, Cookie…
Vary: User-Agent
It is possible that different content is served to desktop and mobile users. The site distinguishes between two types of visitors as it uses information from the HTTP request of the client. The HTTP User-Agent header, sent from the client, contains information such as browser name and version, user operating system, etc. In such case the website serves the appropriate content depending on the HTTP User-Agent header of the client.
The HTTP header might be added to the server response: Vary: User-Agent
When a user connects directly to the content origin server, the appropriate version is served in compliance with the information in the HTTP User-Agent header.
For example if a web client requests with the following header to the website:
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X)
it will be detected as a mobile user so the server will respond with the mobile version.
If the header is:
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv: 42.0) Gecko/20100101 Firefox/42.0
the desktop version will be served to the client;
This very difference shall be taken into consideration by caching services and crawling bots when they index a page. Hence desktop versions will be served to desktop users and mobile versions will be respectively served to mobile users.
If the origin server doesn’t send the header Vary: User-Agent, this may lead to the following situations:
– Web cache/proxy: Web cache first is accessed by a desktop user looking up for a certain page. The caching server requests and receives this page content from the origin server (does not receive the Vary header: User-Agent). Then the web cache forwards the desktop version of the page and makes a copy of it. Afterwards, the web cache is accessed by a mobile user who is looking up the same page. Since the caching server does not know that it should check the HTTP User-Agent header, it does not differentiate between the first and the second user so it serves the available desktop version.
– Search engines and their bots: When crawling a website Googlebots might present themselves as different mobile devices or browsers, trying to access and index each website version. If the Vary header: User-Agent is not sent to the bots they will not recognize other website versions except for the indexed one. Indexing different versions will be useful afterwards, when this webpage is looked up by users. The search engine will redirect the users to the right version depending on whether they are mobile or desktop users.
Vary: Accept-Encoding
Another Vary header case of use is when a website serves compressed content. The header uses compatibility with browsers’ older versions or web clients which cannot process compressed content. If the web client does not send the Accept-Encoding header: gzip,deflate,sdch, the server will respond with uncompressed content.
The header will be added to the server response: Vary: Accept-Encoding
If you have enabled static content compression through cPanel -> Compression settings, HTTP Vary Header: Accept-Encoding is automatically set and you do not need to enable it through the .htaccess file. Static content compression is managed from the Apache module – mod_deflate.
When a specific web client supports compressed content processing this will be announced to the server with the following header:
Accept-Encoding: gzip,deflate,sdch
In this way the server will know that the client supports compressed content and will send it there along with the Content-Encoding header: gzip.
If the origin server doesn’t send the header Vary: Accept-Encoding, this may lead to the following situation:
– Web cache/proxy: А web client that supports compressed content processing will access the website through web cache/proxy. Then the web cache will serve the compressed content from the origin server as a response and will forward it to the client. The web cache/proxy saves the compressed version. When the same website is looked up by a web client unable to process compressed content, the web cache does not know that availability of the Accept-Encoding header must be checked so it sends the same compressed content. Hence the website cannot be loaded by the web client.
Managing HTTP Vary Header
HTTP headers (of HTTP request and HTTP response) might be configured in the Apache module (mod_headers) through modifying the .htaccess file.
For example when file types such as .js, .css, .xml or gz are sent to web clients they also receive the Vary: Accept-Encoding:
<IfModule mod_headers.c>
<FilesMatch "\.(js|css|xml|gz)$">
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>HTTP headers can be also managed through the applications of the hosting account. Vary header, for example, might be configured through PHP in the following way:
<?php
header("Vary: User-Agent");
?>or on a WordPress website (from the functions.php file)
function add_vary_header ($headers)
{
$headers['Vary'] = 'User-Agent';
Return $headers;
}
add_filter('wp_headers', 'add_vary_header');