Caching

ETags: free-recall review

Crux Free-recall prompts across the ETag unit. Answer each in your own words first, then reveal the model answer and compare.

Your altitude — climbing toward senior

ZeroJuniorMiddleSenior

You are at senior altitude — in orbit

◷ 13 min

Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick when you are staring at a real DevTools timeline.

Goal

Reconstruct the unit’s spine — what a 304 saves, the fingerprint-echo-compare handshake, strong vs weak validators, ETag vs Last-Modified, and the per-node failure — without looking back at the lesson.

Recall before you leave

01
A teammate says ETags make repeat requests free. Correct them precisely: what does a 304 save, and what does it still cost?
02
Walk through the conditional-request handshake end to end, naming the headers and statuses.
03
Explain strong vs weak validators and where the distinction actually matters.
04
Compare ETag and Last-Modified. When is Last-Modified not enough, and why?
05
Why does adding a second and third server commonly kill 304s, and how do you make ETags load-balancer-safe?
06
How does compression interact with a strong ETag, and what is the trap?

Recap

If you could reconstruct each answer from memory, you hold the unit’s spine: a 304 saves the body, never the round-trip; the handshake is fingerprint-echo-compare over ETag and If-None-Match; strong validators promise byte identity and weak ones semantic equivalence, with If-None-Match comparing weakly so the difference mainly matters for ranges; ETags beat Last-Modified’s one-second blind spot; and revalidation only survives behind a load balancer when the ETag is a pure function of the content — including the content’s encoding.

Continue the climb ↑ETags: reading HTTP exchanges