Cache-Control Directives

Cache-Control directives control whether HTTP responses can be stored, when they may be reused, and when a cache must revalidate them. They can appear in requests, responses, or both, depending on the directive.

`Cache-Control` is an HTTP header containing one or more comma-separated directives. Response directives tell caches and clients how a response may be stored and reused; request directives can influence how an intermediary handles a request. Common response directives include `public`, `private`, `no-cache`, `no-store`, `max-age`, and `must-revalidate`.

`max-age` specifies how many seconds a response can be considered fresh after it is received. `no-store` is stronger: it instructs caches not to store the response. `no-cache` does not mean "never cache"; it permits storage but requires validation before reuse when validation is required.

`private` indicates that a response is intended for a single user and should not be stored by a shared cache. `public` explicitly permits shared caching when other HTTP requirements allow it. These directives are especially relevant when a Java backend returns user-specific or otherwise cacheable HTTP resources.

Caching and freshness are separate from validation. Validators such as `ETag` and `Last-Modified` allow a cache to ask the server whether its stored response is still valid, potentially receiving `304 Not Modified` instead of the complete representation.

Key points

• `max-age` controls freshness duration in seconds.
• `no-store` tells caches not to store the response.
• `no-cache` permits storage but requires validation before reuse when applicable.
• `private` is intended for user-specific responses and shared caches.
• `ETag` and `Last-Modified` support revalidation rather than defining freshness themselves.

Interview questions

What does `max-age` mean in a response?

`max-age` specifies the maximum freshness lifetime in seconds. For example, `Cache-Control: max-age=300` allows a cache to reuse the response while it is fresh for 300 seconds under the applicable caching rules. After that period, the cache generally needs to revalidate or obtain a new response before reuse.

Why would an API response use `private`?

`private` indicates that the response is intended for a single user and should not be stored by a shared cache. This is useful when a response depends on the authenticated user or contains personalized data. A private browser cache can still store the response when other caching rules permit it.

What does the HTTP `Cache-Control` header do?

`Cache-Control` defines caching behavior for an HTTP request or response. Its directives can control whether a response is stored, how long it remains fresh, and whether validation is required before reuse. For example, `max-age=60` permits reuse while fresh for 60 seconds, while `no-store` prevents storage.

What is the difference between `no-cache` and `no-store`?

`no-store` tells caches not to store the response. `no-cache` is different: a response may be stored, but the cache must validate it before reusing it when validation is required. Therefore, `no-cache` can still benefit from caching while `no-store` prevents that storage.

How do `Cache-Control` and validators such as `ETag` work together?

`Cache-Control` can determine how long a stored response is considered fresh and whether validation is required. An `ETag` supplies an identifier for a particular representation. When a cache needs to validate its stored copy, it can send the validator in a conditional request, allowing the server to return `304 Not Modified` when the representation has not changed.