Questions › Networking/Security

Conditional requests: ETag, Last-Modified, and 304

CachingEasyNetworking/Security

How do conditional requests work? Explain ETag / If-None-Match and the 304 Not Modified response.

What it tests

Understanding HTTP validation — how the browser confirms a cached copy is still fresh without re-downloading it.

Approach & answer

Conditional requests let a client REVALIDATE a cached resource cheaply: instead of re-downloading, it asks 'has this changed since the version I have?' and the server answers with either the new content or a tiny '304 Not Modified' meaning 'your copy is still good'. Two validators drive this. An ETAG is an opaque identifier the server assigns to a specific version of a resource (often a hash or version tag), sent in the response as ETag: "abc123". On the next request the browser sends If-None-Match: "abc123"; if the server's current ETag still matches, it replies 304 with no body, and the browser uses its cached copy. If it differs, the server sends 200 with the new body and a new ETag. LAST-MODIFIED is the time-based equivalent: the server sends Last-Modified: <date>, and the browser revalidates with If-Modified-Since: <date>; the server returns 304 if unchanged or 200 with fresh content otherwise. ETags are more precise than timestamps (they catch sub-second changes and content that changed then changed back to identical bytes — a 'strong' ETag can even signal byte-identical content). Why this matters: revalidation saves BANDWIDTH and time — a 304 is a few bytes of headers versus re-transferring a whole file — while still guaranteeing freshness, which is the sweet spot between 'always re-download' (wasteful) and 'trust the cache blindly' (risks staleness). This complements, rather than replaces, freshness caching via Cache-Control: max-age tells the browser it can use the cached copy WITHOUT even asking for a period; once that expires (or with no-cache / must-revalidate), the conditional request kicks in to check before reusing. The typical strong setup pairs long max-age with content-hashed filenames for static assets (never revalidate until the URL changes) and short max-age + ETag for dynamic resources (cheap revalidation). So 304 is the browser and server agreeing 'nothing changed, don't waste the transfer'.

Use this technique when

Explaining a 304 in the Network tab; designing cache revalidation; reducing redundant transfers.

Code

First response:              Next request (revalidate):
  200 OK                        GET /logo.png HTTP/1.1
  ETag: "abc123"                If-None-Match: "abc123"
  Cache-Control: max-age=60
  <image bytes>              Server compares current ETag:
                               unchanged -> 304 Not Modified (no body, use cache)
                               changed   -> 200 OK + new bytes + new ETag

Last-Modified / If-Modified-Since = the time-based equivalent (less precise).
max-age = use cache WITHOUT asking; conditional request = cheap check when it expires.
304 = "nothing changed, skip the transfer" (a few header bytes vs the whole file).

References