ETags: free-recall review
Free-recall prompts across the ETag unit. Answer each in your own words first, then reveal the model answer and compare.
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.
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.
- 01A teammate says ETags make repeat requests free. Correct them precisely: what does a 304 save, and what does it still cost?
- 02Walk through the conditional-request handshake end to end, naming the headers and statuses.
- 03Explain strong vs weak validators and where the distinction actually matters.
- 04Compare ETag and Last-Modified. When is Last-Modified not enough, and why?
- 05Why does adding a second and third server commonly kill 304s, and how do you make ETags load-balancer-safe?
- 06How does compression interact with a strong ETag, and what is the trap?
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. Now when a teammate ships a multi-pod API with caching “enabled,” you’ll know the first question to ask: is the ETag derived from the content, or from something that lives only on one machine?
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.