Using Cache-Control Headers

Definition

Cache-control headers (CCH) are pieces of file information that make it possible to define how your pages are handled by caches. Servers and clients can use them to interact with each other through the file or to create some action with the file itself. CDN clients and system administrators who manage system interaction through HTTP need to understand CCH. When talking about caching, you have to consider CCH because these headers are responsible for how different systems deal with the local cache and files. Different systems react differently and honor these headers in a different fashion. Nginx! We use it because it’s providing a great deal of flexibility and it’s easy to manage, especially if there are hundreds/thousands of vhosts to deal with. So now, the logical question appears to be, what Cache-Control headers are being honored and which aren’t as this may become a “first plan” occupation for all new Nginx based services. Most common CCH would look like:

Cache-Control: public, max-age=86400

To go through different variations, list the following with the description:

private and public

These parameters in CCH (Cache-Control: private OR Cache-Control: public) tell proxy servers if the response for the file is unique for a single requester. The proxy servers will then know to pass the response without caching it locally.

Examples of Cache-Control Headers

max-age=(time in seconds)

The override expires header sets a new value to define the length of time, in seconds, to cache the file or resource. Typically, this header will be applied everywhere between source and destination. When the resource is passed from origin through Nginx, the header will be applied and the file will be cached for the duration defined. Nginx then passes this value to source browsers, as well.

s-maxage=(time in seconds)

This one also defines the CDN caching time. You can override max-age and expires headers to define a new value for CDN caching. Keep in mind that Nginx will usually not honor this header, so it won’t take effect on our servers. However, Nginx does work with X-Accel-Expires, which does the same thing.

no-cache

This prevents the caching of a resource if no other parameter is defined alongside no-cache. You can re-validate the assets by the headers added alongside it. When using CDN, it is best to remove no-cache from the list of headers so it does not pile up the percentage of cache misses.

no-store

This will cause all intermediate servers to drop the caching for resources. They will not cache a request for that file or resource.

must-revalidate

This one will force caching systems to validate the requested asset upon each request before the file is served. This header overrides caching rules and makes sure that no stale content is ever served. This header is not always honored. It has an aggressive nature, so some admins, like Nginx, will ignore it to preserve rational HIT percentage.

proxy-revalidate

Proxy-revalidate compares its use against must-revalidate, then instructs CDN servers to behave as described. While must-revalidate can be applied to user agents, proxy-revalidate will be valid only on intermediate servers (CDN’s).

If you have any questions or experience any issues, please reach out to the Support Team, live chat and ticket support are available 24/7.