Gotcha: HTTP caching headers interaction

Incorrect caching headers cause stale content served to users or resources not being cached when they should be.

Understanding Cache-Control directive interactions:

# Static assets (immutable, long cache)
Cache-Control: public, max-age=31536000, immutable
# Use with content-hashed filenames: app.a1b2c3.js

# API responses (never cache)
Cache-Control: no-store
# NOT no-cache! no-cache means "revalidate every time"

# HTML pages (revalidate each time)
Cache-Control: no-cache
# Or equivalently:
Cache-Control: max-age=0, must-revalidate

# Private data (user-specific)
Cache-Control: private, max-age=300
# CDNs won't cache this, only browser

# CDN-friendly with revalidation
Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=86400

Common mistakes:

• no-cache does NOT mean 'don't cache' - it means 'always revalidate'
• no-store means 'don't cache at all'
• Missing Vary: Accept-Encoding causes wrong compressed version served
• ETag without Cache-Control still gets cached by browsers
• max-age=0 without must-revalidate allows stale content
• Setting cache headers on error responses (404s cached!)

For versioned assets:

app.js            -> Cache-Control: no-cache (entry point)
app.a1b2c3.js     -> Cache-Control: public, max-age=31536000, immutable
style.d4e5f6.css  -> Cache-Control: public, max-age=31536000, immutable

no-cache and no-store are the most commonly confused directives. Getting caching wrong either wastes bandwidth or serves stale content.

Web applications needing correct HTTP caching behavior