HTTP caching

Enables efficient cache validation and conditional requests by attaching a version identifier to resources.

Web APIs: implementing conditional GET requests with If-None-Match headers; REST services: supporting optimistic concurrency control via If-Match headers; CDN/proxy layers: validating cached responses against origin servers

REST APIs, HTTP middleware, CDN configurations, web frameworks (Express, Django, Spring, FastAPI), browser caching

client sends conditional header → server checks ETag match → returns 304 Not Modified or 200 with new ETag

• If-None-Match
• If-Match
• Cache-Control
• Last-Modified
• 304 Not Modified
• weak/strong validators

• Last-Modified/If-Modified-Since: simpler timestamp-based validation but second-precision
• Cache-Control with max-age: avoids revalidation entirely but risks stale data
• Content-Hash in URL: forces cache busting but breaks URL stability

Using weak ETags (W/"...") for byte-level comparison: causes unnecessary 200 responses when content is semantically identical; Forgetting to send ETag on 304 responses: breaks the validation contract; Comparing ETags without quotes: the ETag value must be a quoted opaque-tag per RFC 7232; Using ETags generated from filesystem mtimes in distributed systems: causes false misses when inodes differ across servers; Setting ETag to MD5 of full body for large files: expensive to compute and defeats the purpose of conditional requests

Last-Modified header: timestamp-based rather than opaque identifier; Cache-Control: controls freshness rather than validation; Vary header: affects cache key selection rather than resource identity

Coming from PHP: may rely on default ETag generation from Apache which uses inode-based tags that break across load-balanced servers → use explicit application-generated ETags; Coming from static-site generators: may assume ETags are always strong → distinguish strong vs weak validators per RFC 7232

• HTTP caching headers
• Cache-Control
• Last-Modified
• If-None-Match
• If-Match
• 304 Not Modified

When NOT to use: skip ETags for Cache-Control: no-store responses or when responses are personalized per request; Performance: ETag computation should be cheap (hash of normalized representation, not raw bytes); Boundary conditions: weak vs strong comparison semantics differ — strong comparison requires byte-identical representations while weak allows semantically equivalent

Reduces bandwidth consumption and improves perceived latency by allowing clients to skip re-downloading unchanged resources, while enabling safe optimistic concurrency for distributed writes.

ETag header: like a fingerprint on a package — if the fingerprint matches what you already have, you don't need to open the box again.

Conditional request patterns with If-Match for optimistic concurrency control