In this week’s Two Minute Tech Tuesday, we're talking about cache variations.
As the name implies, cache variations are variations of a cached object. Before we can talk about them, we need to look at how regular objects are identified in the cache. For that, we'll use the URL and more specifically, the host and the path section. These values are used to create a hash that is used to look up the object in the cache:
What if your page also depends on a request header such as the Accept-Language header, used to create multilingual content.
This header could have, for example, English or Dutch content, but it’s pretty much a first-come, first-served business. Because the first one that requests the content uses its language and the object gets stored in the cache. This is unacceptable: the wrong language would be presented if there were no variations.
So it's obvious that cache variations serve a purpose. And issuing a cache variation can be done through a Vary response header where the value is a valid request header:
In this case, we're performing a cache variation based on the Accept-Language header. As this diagram illustrates, the main object identified by example.com/ has an English variation and a Dutch variation.
Depending on the Accept-Language header presented by the request, different content will be returned.
But what happens if you use a language cookie? And how do you create those variations? Could you do a Vary: Cookie? Yes, but there are risks involved. Imagine the following cookie:
It has a unique Google Analytics tracking code and then a language cookie on which we want to do the variation. The problem is that this cookie will create a unique variation for every user, which jeopardizes the hit rate. The solution is to write some VCL and remove all the cookies from the Cookie header except the language cookie. If you're using Varnish Enterprise you have a clean API and you can do this through cookieplus.keep():
That will allow you to safely perform a Vary: Cookie.
There's also another solution that doesn't require a Vary: Cookie. You can extend vcl_hash and add the cookie to it by identifying whether or not there is a cookie and if it fits the right value performing a hash_data() on the cookie value:
If you're using Varnish Enterprise, again there's a clean API through the cookieplus VMOD, so it's a matter of performing a hash_data() on the cookieplus.get("language") cookie
Hopefully this shows how useful and important cache variations are. Even though the URL is a unique identifier, the content may not be unique and it may depend on certain request headers, so keep that in mind. Use the Vary header, use it carefully and write the necessary VCL to counter some aspects of it.
Stay tuned for next week's episode, presented to you in two minutes or less!