Quiz
Warm-up from lesson 4-3: GET requests must be "safe", they read without changing anything. Why does that make GET responses ideal for caching?
The fastest request is no request
Your browser keeps a cache: a folder of responses it already received. If a page's logo can be reused from disk, the browser skips the entire lesson 1-2 journey for it: no DNS, no TCP, no TLS, no request. That is why the second visit to a site feels instant.
But reusing a stored copy is only correct if the server allows it. The server grants permission per response with the Cache-Control header:
Cache-Control: public, max-age=86400The common directives:
max-age=86400: this copy is fresh for 86400 seconds (24 hours). Reuse it freely until then.no-store: never store this (bank balances, personal data).no-cache: store it, but re-check with the server before each reuse.public/private: whether shared caches between you and the server (like the CDNs in the next lesson) may store it, or only your own browser.
There is also a clever middle ground. The server can tag a response with a version fingerprint header, ETag: "abc123". When the cached copy goes stale, the browser asks: If-None-Match: "abc123". If the content has not changed, the server answers 304 Not Modified with no body, and the browser keeps using its copy. You met 304 in the lesson 4-3 table, this is where it comes from.
Code exercise · bash
Run this. It pulls the max-age value out of a raw Cache-Control header, the same trim-until-the-interesting-part technique you have used since lesson 1-2, and converts it to hours.
Code exercise · bash
Your turn. Write a tiny cache-policy reader: for each header, print "never cache" if it contains no-store, otherwise print "cache for N seconds" using its max-age value. A case statement with *no-store* and *max-age=* patterns handles the branching (like your status-code classifier in lesson 4-3).
Quiz
A browser re-checks a stale cached file and gets 304 Not Modified. What travels in that response's body?