HTTP Cache Header Builder

The `immutable` directive tells browsers that the response body will never change during its freshness lifetime. This prevents browsers from sending conditional revalidation requests (If-None-Match / If-Modified-Since) even when the user manually refreshes. Use it only for content-hashed assets like `bundle.a3f7c2.js` where the filename changes when content changes.

stale-while-revalidate allows browsers to serve a cached (stale) response immediately while fetching a fresh version in the background. It's ideal for API responses and pages where slight staleness is acceptable but you want near-instant loads. Example: `Cache-Control: max-age=60, stale-while-revalidate=3600` — serve from cache for 1 min, then background-revalidate for up to 1 hour.

The `Vary` header tells caches which request headers affect the response content. For example, `Vary: Accept-Encoding` means the cache must store separate versions for gzip and non-gzip clients. `Vary: Accept-Language` stores language-specific versions. Misconfiguring Vary can cause cache thrashing (too many variants) or serving wrong content to users.

No — if your filenames include a content hash (like bundle.a3f7c2.js), the URL itself changes when content changes. ETags provide no additional benefit and add unnecessary server overhead for revalidation requests. ETags are most valuable for content without cache-busting URLs, like HTML pages, API responses, or image files with stable names.

Cache-First serves from cache immediately, falling back to network if not cached — best for static assets that rarely change. Network-First always tries the network first and falls back to cache on failure — best for dynamic content where freshness matters. Stale-While-Revalidate serves cached content immediately and updates the cache in the background — best for frequently updated but non-critical content.