Validation: ETag, Last-Modified and Vary

Asking "has it changed?" cheaply

When a cached response becomes stale (or is marked no-cache), the cache can revalidate instead of downloading everything again. The server sends a validator with the original response: an ETag (an opaque version identifier, often a hash of the content) or Last-Modified (a timestamp). On revalidation, the client sends If-None-Match: "etag" or If-Modified-Since; if nothing changed, the server replies 304 Not Modified with no body, saving bandwidth and often work. Strong ETags mean byte-identical content; weak ETags (W/"...") mean semantically equivalent. The Vary header tells caches which request headers change the response, so they store separate variants: Vary: Accept-Encoding for gzip versus Brotli, Vary: Accept-Language for translations. Use Vary sparingly: varying on User-Agent or Cookie fragments the cache into near-uselessness.

A revalidation exchange

The second request sends the ETag; the server answers 304 with no body.

GET /api/products/42 HTTP/1.1
Host: shop.example.com

HTTP/1.1 200 OK
Cache-Control: public, max-age=60
ETag: "p42-v17"
Vary: Accept-Encoding
Content-Type: application/json

{ "id": 42, "name": "Notebook", "priceMinor": 4999 }

# 2 minutes later, the cached copy is stale:
GET /api/products/42 HTTP/1.1
Host: shop.example.com
If-None-Match: "p42-v17"

HTTP/1.1 304 Not Modified
Cache-Control: public, max-age=60
ETag: "p42-v17"

Asking for the newspaper's edition number

Instead of buying today's paper again, you ask the vendor "Is edition 17 still the latest?" A quick "yes" (304) saves you carrying a whole new paper home.

Quick check: What does a 304 Not Modified response mean?

• The resource was deleted
• The cached copy is still valid and can be reused; no body is sent
• The server is down
• The client must not cache the response