HTTP Caching

In this chapter

We'll go deep on real HTTP caching — the standardized Cache-Control header that governs browsers, proxies, and CDNs — and find the exact, precise gap behind GreenMart's own incident: no header at all, letting the proxy apply its own reasonable, uncoordinated default.

8–10 min

The Problem in Real Life

Sarah finally opens the exact response headers from the stock page. "Here it is," she says. "No Cache-Control header at all. The proxy picked its own default because GreenMart's own server never actually said anything."

Mike looks at the blank space where a real instruction should have been. "So the server just... never told it what to do?"

If the server never says how long to cache something, what actually happens?

Mike

Silence vs. A Real, Explicit Instruction

Cache-Control — the real, explicit instruction

A real header controlling max-age, no-store, no-cache, and private/public — the standard mechanism behind HTTP caching.

Silence isn't neutral

A missing Cache-Control header doesn't disable caching — it lets every intermediate layer apply its own uncoordinated default instead.

HTTP caching is the real, standardized mechanism browsers, proxies, and CDNs use to cache whole HTTP responses — governed by real, explicit headers a server sends with every response. When a server stays silent, intermediate systems don't ask; they apply their own real, reasonable-sounding defaults, exactly as GreenMart's own proxy did.

`Cache-Control` — the real, primary instruction. A server attaches a Cache-Control header to a response, and its real directives control exactly how caching should behave: max-age=300 (cache this for 300 real seconds), no-store (never cache this at all, anywhere), no-cache (cache it, but always check back before reusing it — a real, different rule than the name suggests), and private vs. public (whether only the requesting browser may cache it, or any shared intermediate cache — like GreenMart's own proxy — may too).
GreenMart's own real gap, named precisely. With no Cache-Control header present at all, GreenMart's proxy fell back to its own real, built-in heuristic — a common, genuinely reasonable default among real caching systems, but one GreenMart never actually chose. The fix isn't removing caching; it's GreenMart's own server finally saying, explicitly, exactly what should happen: Cache-Control: private, no-store for the stock count specifically, since that data is both directly harmful when stale and genuinely private to a live request, not something any shared proxy should be allowed to cache on GreenMart's behalf at all.
Expiration headers — the older, real precursor. Before Cache-Control was standardized, an older header, Expires, set a real, fixed date/time after which a response should be considered stale — still supported today, but genuinely less flexible than Cache-Control's own directives, and generally treated as a fallback for caches that don't understand the newer header.
HTTP caching is genuinely layered, not one single cache. A response can be cached by the requesting browser itself, by any shared proxy sitting in between (like GreenMart's own), and by a CDN (a later chapter's own subject) — each real layer respects the same Cache-Control header, but each is a genuinely separate cache with its own copy, which is exactly why GreenMart discovering and fixing one layer doesn't automatically fix every layer at once.

Table — Common Cache-Control Directives

Directive	Real Meaning
max-age=300	Cache this response for 300 real seconds
no-store	Never cache this response, anywhere, at all
no-cache	May be cached, but must be revalidated before every real reuse
private	Only the requesting browser may cache this — no shared/intermediate cache
public	Any cache, including shared intermediate ones, may store this

GreenMart's stock count endpoint needed private, no-store — directly harmful when stale, and specific to one live request, not something a shared proxy should ever cache on the site's behalf.

GreenMart now has the real, exact instruction the stock page was missing — not a mysterious caching bug, but a real, standard header that was simply never sent, letting every intermediate layer make its own reasonable, uncoordinated guess instead.

Key Takeaway

HTTP caching is governed by real, explicit headers, chiefly Cache-Control — when a server stays silent, browsers and proxies don't ask permission, they apply their own reasonable defaults, which is exactly the real gap that let GreenMart's stock page go stale invisibly.

Why This Matters

Every response GreenMart's own servers send — a product page, a stock endpoint, a static image — passes through real HTTP caching layers whether or not GreenMart ever configures them deliberately. Sending explicit, correct Cache-Control headers is the one real, direct way GreenMart controls what happens at every one of those layers at once.

GreenMart now has the exact real header — Cache-Control — governing the browser/proxy layer that caused its own incident. The next chapter meets a real complementary mechanism: ETags, which let a cache check whether stale-looking data has actually changed, instead of just trusting a timer.