Cache Control

The HTTP Cache-Control header contains directives—specific instructions that guide how browsers and shared caches like proxies and Content Delivery Networks (CDNs) store and serve content. These directives are applicable in both requests and responses, playing a critical role in controlling caching behavior to optimize performance and ensure content freshness.

Note: Properly configuring cache directives can help improve website load times while maintaining content integrity.

Syntax

Cache directives follow a set of standardized rules to ensure proper implementation and compatibility across different systems. These directives control how, when, and for how long resources are cached by browsers and other caches.

Note: Proper use of cache directives can enhance website performance and reduce bandwidth usage by minimizing unnecessary data transfers.

• Cache directives are case-insensitive; however, it is recommended to use lowercase for consistency, as some implementations may not recognize uppercase directives.
• Multiple directives may be used together and should be separated by commas, such as Cache-control: max-age=180, public.
• Some directives accept optional arguments, which are separated from the directive name by an equals sign (=). Arguments are typically integers and are not enclosed in quotes, for example, Cache-control: max-age=12.

Directives

The following list covers the standard Cache-Control directives and their typical usage. Some directives are primarily used in responses, while others are used in requests. Not all directives are supported by every user agent; it’s important to check compatibility tables to ensure proper behavior. User agents that do not recognize certain directives will ignore them.

Note: Check the compatibility table for their support; user agents that don’t recognize them should ignore them.

This section explains key terms related to caching, many of which originate from the HTTP specifications.

(HTTP) cache

An implementation that stores requests and responses for future reuse. Caches can be shared (e.g., proxies or CDNs) or private (e.g., browser cache).

Shared cache

A cache located between the origin server and multiple clients, such as a proxy or CDN. It stores responses to serve multiple users but should avoid caching personalized content.

Private cache

A cache dedicated to a single user, like a browser cache. It can store personalized content and user-specific sessions.

Store response

The act of saving a cacheable response. While storing is straightforward, cached responses might be subject to validation before reuse.

Reuse response

Using cached responses for subsequent requests, possibly after validating their freshness.

Revalidate response

Asking the origin server whether the stored response remains fresh. This is often done via conditional requests.

Fresh response

Indicates that a response is fresh and can be reused without validation, based on specific directives or headers.

Stale response

Refers to a response that is no longer fresh. It may still be used temporarily, typically after validation or using specific cache directives.

Age

The amount of time since a response was generated. It affects whether the response qualifies as fresh or stale.

Response Directives

max-age=N

The max-age=N directive indicates that the response remains fresh for N seconds after it was generated. It guides caches on how long they can serve the cached response without revalidation. For example:

Cache-Control: max-age=604800

This means caches can store and reuse this response for up to one week while it’s fresh.

Note: max-age is the elapsed time since the response was generated on the origin server, not received by the cache. If intermediate caches add their own Age headers, the cache deducts that time from the freshness lifetime.

Cache-Control: max-age=604800
Age: 100

s-maxage

The s-maxage directive specifies how long a response is considered fresh in shared caches. It overrides max-age for shared caches but is ignored by private caches.

Cache-Control: s-maxage=604800

no-cache

The no-cache directive indicates that stored responses must be validated with the origin server before reuse, even if they are still fresh. It permits storage but enforces revalidation.

Cache-Control: no-cache

To always check for updates, use no-cache. Remember, this does not prevent caching; it requires validation before reuse. If you want to prevent caching altogether, use no-store.

must-revalidate

This directive indicates that a cached response must be revalidated with the origin server once it becomes stale. It is often used with max-age to prevent serving stale responses when offline or disconnected.

Cache-Control: max-age=604800, must-revalidate

proxy-revalidate

Similar to must-revalidate, but specifically applies to shared caches like proxies.

no-store

The no-store directive instructs caches of any kind not to store the response at all.

Cache-Control: no-store

Use no-store when privacy is critical or responses contain sensitive data.

private

The private directive indicates that a response can be stored only in a private cache, not shared caches like proxies.

Cache-Control: private

Include this for user-specific data, such as personalized pages or user accounts, especially after login. Omitting private may risk personal information being stored in shared caches.

public

The public directive allows responses to be stored in both shared and private caches regardless of authentication requirements.

Cache-Control: public

Useful for static assets like images or stylesheets that don’t contain sensitive information. When combined with max-age or s-maxage, it makes responses widely cacheable.

Note: For pages requiring authentication, responses with Authorization headers are typically not cacheable unless public is used explicitly. Otherwise, privacy may be compromised.

;

must-understand

This directive indicates that a cache should only store responses if it understands the caching requirements based on status code or other protocols. It is usually coupled with no-store to enforce strict compliance.

Cache-Control: must-understand, no-store

no-transform

The no-transform directive advises caches and intermediaries not to modify or alter the response content, such as compressing images or changing formats.

immutable

The immutable directive indicates the response will not change during its fresh lifetime. This allows caches

How to Modify Header using Requestly

Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Cache-Control header. This is especially useful when you want to test how your application handles caching or troubleshoot caching-related issues during development. Steps to Modify the Cache-Control Header:

1. Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
2. Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
3. Add a new header modification:
   • Under “Action”, select “Add” or “Override”.
   • In the “Header Name” field, enter Cache-Control.
   • In the “Header Value” field, enter your desired cache directive (e.g., no-cache).
4. Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/\*).
5. Save the rule.

Once set up, Requestly will inject the Cache-Control header into all matching requests, allowing you to control or test caching behavior as needed.