LiteSpeed Cache Vary

The Cache Vary is an important concept for caching. For simplicity's sake, the idea behind cache varies is that it allows the cache to save multiple versions of the same URL.

1. Differences between Desktop and Mobile views. Specifically, the html for the desktop and mobile views do not match. This could be because of a non-responsive theme, different widgets loading, or otherwise.
2. Global audience/multi-lingual support. If the url must stay the same, it is possible to vary on the language.

LiteSpeed Servers can vary on cookies. The server needs to be instructed about the cookie NAME to vary on. The server will then use the cookie VALUE as part of the cache key.

For Example, suppose the server is instructed to vary on the cookie 'my_cookie'.

• Request A has NO cookies.
• Request B has the cookie my_cookie = Alabama
• Request C has the cookie my_cookie = California
• Request D has the cookie my_cookie = Alabama

For this example, Requests B and D will get the same cached version (or another way to see it: request B can generate the cache entry for request D). Their cache entry will differ from requests A and C, both of which have a unique cache entry. So there are 3 total cache entries.

By default, LiteSpeed servers will recognize any cookie that starts with '_lscache_vary' as a vary cookie.

The Cache Vary Value is a value used to vary a request. Only one vary value may be used. If multiple are set, only the last one will be used.

An example use case is the separate mobile view example listed above. Given the request's user agent, if it matches a mobile browser, one can set vary value = 'ismobile'.

Custom varies should be used if the contents of the site changes depending on controllable circumstances, such as when a User Agent matches something or if a cookie exists and has a specific value. Custom cookie varies can also be used to prevent conflicting login situations, as described here.

Rewrite Rules can be used to vary the request when it comes in.

Example:

RewriteRule .? - [E=Cache-Vary:my_cookie]

This example rewrite rule will instruct the server to check for the “my_cookie” cookie NAME and if it exists, vary on it.

As of LSWS version 5.1.x and OLS 1.4.x, it is possible to add more vary cookies to the rewrite rule.

Example:

RewriteRule .* - [E=“cache-vary:xf_style_id,xf_language_id”]

Example:

RewriteCond %{HTTP_USER_AGENT} Mobile|Android|Silk/|Kindle|BlackBerry|Opera\ Mini|Opera\ Mobi [NC] RewriteRule .* - [E=Cache-Control:vary=ismobile]

This example rewrite rule checks the user agent for a mobile browser agent. If it matches, it will add the vary value “ismobile” to the request.

NOTICE: Examine the examples closely. Note that for the vary cookie, it uses “E=Cache-Vary:”, and for the vary value, it uses “E=Cache-Control:vary=”. These are how to differentiate the two.

Response headers can be used to instruct the server to cache the page with the listed varies in mind.

Note that the response headers should be used if the cache vary is meant to be on a per page basis. For example, the WordPress plugin uses the response header to vary password protected pages on the password cookie. There is no reason to vary on the password cookie on non password protected pages, so to cache smarter, only the password protected pages will use the vary.

Example header:

X-LiteSpeed-Vary: cookie=my_cookie,value=ismobile

For the pages with that vary header, the server will compare against that cookie and value.

The Vary Value response header has a special meaning, because requests do not necessarily come in with a vary value. This response header is meant to be used in conjunction with the vary value rewrite rule. An example scenario using this case would be if a browser was initially detected as a desktop browser, but was actually loading a mobile view. Using the response header, the server can be notified that the page should actually be cached with the “ismobile” value.