ETags & Conditional Requests

In this chapter

We'll meet ETags and conditional requests — a real content fingerprint and the mechanism a cache uses to cheaply confirm whether a stale-looking copy has actually changed, getting a real 304 Not Modified instead of paying for a full re-download when nothing did.

7–9 min

The Problem in Real Life

Mike remembers something from the last chapter. "You mentioned no-cache doesn't actually mean 'don't cache' — it means 'check first.' Check how, exactly?"

Sarah grins. "Now we're at the real mechanism. It's genuinely clever — a cache can ask a real, tiny question instead of re-downloading the whole real answer."

How does a cache actually 'check' if something changed, without just re-fetching everything?

Mike

Trusting Blindly vs. Asking a Real, Cheap Question First

An ETag is a real content fingerprint

A short identifier that changes if and only if the resource's actual content changes — not a timestamp.

A cheap check instead of a full re-fetch

A conditional request asks 'has this changed?' — a real 304 Not Modified confirms a stale-looking copy is still good, at a fraction of the cost.

An ETag (entity tag) is a real, short identifier a server attaches to a response, representing the exact current state of that resource. A conditional request is how a cache uses that identifier to ask, cheaply, "has this actually changed?" — before ever paying the full real cost of re-downloading it.

What an ETag actually is. A real, short string the server generates for a resource — often a hash of its content — that changes if and only if the resource's real content changes. Two requests for the same unchanged resource get the exact same ETag back; the moment the resource genuinely changes, its ETag changes too. It's a real fingerprint, not a timestamp.
The real conditional request, step by step. A cache holding a stale-by-TTL (or no-cache-flagged) copy doesn't necessarily throw it away — it sends a real request back to the server carrying an If-None-Match header with the ETag it already has. If the server's current ETag still matches, it replies with a real, tiny 304 Not Modified response — no real content at all, just a confirmation — and the cache is now free to keep using its existing copy, fully refreshed in confidence, for a real fraction of the cost of a full re-download.
This is genuinely different from both of Act 4's earlier strategies. Time-based expiry (TTL) trusts a cached copy blindly for a fixed window, with zero real verification. Event-based invalidation requires the write side to proactively signal the cache the moment something changes. ETags offer a real third option: the cache checks in, cheaply, and only pays the real full cost of a fresh copy if something has actually, provably changed — a genuinely different trade-off, useful specifically when a full re-fetch is expensive but a quick "has this changed?" check is cheap.
A close real cousin: Last-Modified. An older, simpler mechanism works the same way using a real timestamp instead of a content fingerprint — a request carries If-Modified-Since, and the server replies 304 Not Modified if nothing's changed since. It's less precise than an ETag (two different real contents saved in the same second look identical to it) but requires no hashing, and is still genuinely useful for resources where that precision doesn't matter.

GreenMart now has a real, third real lever, distinct from a pure timer or a proactive write-side signal: a cache that checks, cheaply and honestly, before deciding whether it actually needs to pay for a full re-fetch.

Key Takeaway

An ETag is a real fingerprint of a resource's current state, and a conditional request is how a cache uses it to ask "has this actually changed?" cheaply — getting the real speed benefit of a cache hit with the real honesty of always checking first.

Why This Matters

For GreenMart's own larger, real assets — product images, downloadable catalogs — ETags let a returning customer's browser confirm nothing changed with a real, tiny request, instead of re-downloading the whole real file every single time, a genuine, direct real bandwidth and speed win.

GreenMart now has three real, distinct caching strategies in hand — time-based, event-based, and validation-based via ETags. The next chapter zooms out geographically: CDNs and edge caching, putting cached copies physically closer to every real customer, wherever they are.