Master HTTP Caching: Using ETag, If-None-Match, and Cache-Control

Fetching resources over the Internet is slow and costly, so HTTP includes cache control mechanisms that let clients reuse previously fetched resources to improve performance and user experience.

Where does cache reside?

Cache exists in browsers and web proxies; servers also have internal caches but they are outside the scope of HTTP caching discussed here. HTTP cache control uses the Cache‑Control response header, and the If‑None‑Match request header together with the ETag response header to validate cache freshness.

ETag response header

ETag (Entity Tag) uniquely identifies a resource, often as a hash or version number, and must change when the resource content changes, forming the basis for HTTP cache validation.

If-None-Match request header

When a browser already has a cached version of a resource with a known ETag, it sends that ETag in the If‑None‑Match header. If the server’s current ETag matches, it replies with a 304 Not Modified status, avoiding retransmission of the resource.

Cache‑Control response header

Cache‑Control defines how and for how long a response may be cached. Directives such as max-age , public , private , no-cache , and no-store control freshness, visibility to shared caches, and whether validation is required before reuse.

max-age specifies the maximum time in seconds that a response can be reused without contacting the server.

public allows caching by any browser or shared proxy; it is the default. private restricts caching to the end‑user’s browser only.

no-cache forces the client to revalidate with the server before using a cached copy, typically using If‑None‑Match and ETag.

no-store prevents any caching of the response by browsers or proxies.

How to decide a resource’s Cache‑Control strategy?

A decision flowchart (illustrated below) helps choose appropriate directives based on resource type, sensitivity, and desired freshness.