a conditional request

Picture phoning a shop to ask only if you have a newer model than the one I bought last March, send it; otherwise don't bother. You avoid receiving a heavy package you already have. A conditional request is the web's version of that call. Instead of plainly asking give me this resource, the client adds a condition based on what it already holds, so the server replies with the full content only if the client's copy is out of date.

It is the mechanism behind cache validation. The two common conditions match the two validators a server can hand out. If-Modified-Since carries the date the client's copy was last changed, so the server checks send the body only if it changed after this time. If-None-Match carries an ETag (a version fingerprint), so the server checks send the body only if the current version differs from this tag. If the client's copy is still current, the server returns 304 Not Modified — a tiny response with headers but no body — and the client reuses what it already has. If the copy is stale, the server returns the normal 200 OK with the full new body and updated validators.

Why it matters: conditional requests are what make staleness affordable. They let a cache keep content past its strict freshness window and then confirm it for the cost of one small round trip, rather than re-downloading megabytes. They also power efficient polling and resumable behavior in many APIs. The honest limit: a conditional request still costs one round trip — so the speed-of-light delay to the server is unavoidable even on a 304. That is precisely why freshness (max-age) is preferred when possible: a still-fresh copy is served with no request at all, while validation is the cheaper fallback once freshness expires.