You only need to debug the cache headers when you use "Site Caching" or "Disabled" as Cache Level. The other cache levels will completely ignore the cache headers.
In order to analyze the cache headers, we'll use a tool called
curl. You can also use the Inspect Tools for your browser.
If you are using Microsoft® Windows, install Git for Windows before proceeding.
Open the Terminal/Git for Windows and run the following command:
curl -IL http://yourdomain.com/
Change "yourdomain.com" for your domain or the complete URL of the page/file. For example, if we want to check Sucuri Blog's front page cache headers, that's how we are going to check:
$ curl -IL https://blog.sucuri.net/ HTTP/1.1 200 OK Server: Sucuri/Cloudproxy Date: Thu, 19 Jan 2017 15:18:31 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding Set-Cookie: PHPSESSID=aha8r2fs3m0njv8h3be14hbtt2; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Cookie Link: <https://blog.sucuri.net/wp-json/>; rel="https://api.w.org/" X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-Sucuri-ID: 11005
Here's the lines we need to pay attention for the purpose of this article:
Vary: Accept-Encoding Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Cookie
It's a powerful header that is frequently used incorrectly. Here's a list of the possible values:
- Vary: Accept-Encoding
When the origin server (your server) doesn't send this header, two things can happen:
1) If the content isn't compressed, you will spent more bandwidth, but all browser will be able to render the page.
2) If the content is compressed, but there isn't a
Vary: Accept-Encoding header, older browsers won't be able to render the content.
To avoid that kind of issue, the origin server must send the
Vary: Accept-Encoding when the content is compressed. That way Sucuri CDN will keep two separate version of your content: one without compression and other with compression. Depending of the browser, Sucuri CDN will serve the right version, saving bandwidth, speeding your website and keeping compatibility to older browsers.
- Vary: Cookie
This header will prevent that authenticated users see cached version of pages designated to guests. It has the same effect as "Cache-Control: private, no-cache" we'll talk about later. With this header, Sucuri CDN will not cache a response to a request that has a Cookie header.
- Vary: User-Agent
If your website has a mobile version, this header can help you with your SEO. It'll make obligatory that cache servers create different versions of the pages depending of the User Agent. Attention: Mobile version is different from Responsive design. Responsive design is interpreted differently by the browser, but the page content is exactly the same for all user agents. You shouldn't use this header for responsive designed websites.
- Vary: Referrer
This header will instruct the browser to re-check with the sever for each different referrer. We don't recommend that you use this header, unless you know exactly what you are doing.
- **Vary: * **
Don't use it. It'll prevent any sort of caching and increase (a lot) the origin server load.
It's the most common and important cache header. It has 2 possible values:
Mainly used for static content and public pages (guests only),
public always comes with
max-age=X (X is seconds) to control the cache life. Actually, when you specify the
max-age=X, it won't be necessary to include
public too, as it's splicity.
It's specially useful for event-driven content websites, like Wikis, news portal, highly updated blogs, etc. You can use Sucuri Firewall cache as a microcaching layer as explained on 8º step of Troubleshoot Caching Issues article.
For websites that doesn't updated the public content frequently, it's even possible to use a longer
If your server doesn't provide a
Cache-Control header specifically for static content, like images, js, css, swf, mp3, mp4, pdf or fonts, our system will automatically set
Cache-Control:"max-age=315360000" for those files.
Side note: the Firewall will check and revalidated (if necessary) those files every 3 days. However, static files will always be cached, regardless of the cache level or the non-cached URLs. Check 4º step of Troubleshoot Caching Issues article in order to know how to avoid static content cache.
It tells to the cache server (Sucuri Firewall) not to cache at all the content. You must combine with
no-store, no-cache, must-revalidate, post-check=0, pre-check=0 to also avoid browser caching. It is commonly used for authenticated users sections and to prevent dynamic content caching.
It's basically a "obsolete" cache-control, used for HTTP/1.0 requests. It has two variables of self-explained meaning:
no-cache. It's still in use because older browser may not support the newest protocols, like HTTP/1.1.
After the date
Expires header explicits, the browser have to request the newest copy of the content. It won't be considered valid after this date, but until there, the local copy should be used. It's expected that
Expires matches the
max-age value of
Cache-Control, but it's not necessary.
Cache-Control, if your server doesn't provide a
Expires header, our system will automatically set a Expires of 20 years for static files.
Caching is one of the most important techniques available to speed your website and save resources, not to mention that it'll be your first defense layer during a attack. You can read more about the cache importance here.
Last-Modifiedheaders weren't mentioned, because they donn't affect the Sucuri Firewall cache behavior.