Cache-Tag header for bulk cache purging
The `Cache-Tag` response header attaches tags to a cached response for later bulk purging. Value is a comma-separated list of tags. Cloudflare consumes this header and strips it before the response reaches the client. Tag constraints: must be printable ASCII (0x21–0x7E, no spaces or Unicode), at most 1024 characters per tag, up to 1000 tags per response, case-insensitive matching at purge time. Invalid tags (over-length, spaces, non-ASCII) are silently dropped; the response is still cached with remaining valid tags.
Range request handling in Workers Caching
Workers Caching serves `Range` requests from a cached full response; the Worker does not implement byte-range slicing. Cloudflare strips the `Range` header before invoking the Worker and requests the full body. The Worker returns a normal 200 response with `Cache-Control`. Cloudflare stores the full response, slices the requested byte range, and returns it as a 206 response. Subsequent Range requests are satisfied entirely from cache without invoking the Worker. If the Worker returns its own 206 response, it is treated as uncacheable and not stored.
Vary header behavior in Workers Caching
When the Worker returns a `Vary` response header, Cloudflare stores a separate cached variant per distinct combination of listed request header values and only returns a variant matching incoming request values. All header names are honored; no allowlist applies. Values are compared verbatim without normalization. `Vary: *` disables caching entirely. Variants share a single purge identity; purging by tag or path invalidates all variants together. Image transformation features take precedence; `Vary` on responses from Polish or Image Resizing is ignored.
Accept-Encoding content negotiation strategies
The Worker controls its own content negotiation for Accept-Encoding. Two strategies: 1. Pick one canonical encoding inside the Worker based on `Accept-Encoding` header, encode once, return single representation. Highest cache hit rate but requires deciding which encoding for each client. 2. Return different `Content-Encoding` per request and set `Vary: Accept-Encoding`. Cloudflare stores one variant per distinct `Accept-Encoding` value. Comparison is verbatim, so equivalent values in different orders create separate variants; normalize `Accept-Encoding` (in a gateway Worker) to control cache fan-out.
Cache-Control header example with stale-while-revalidate
Use Cache-Control headers to control caching duration. Example: "Cache-Control: public, max-age=3600, stale-while-revalidate=300" caches responses for 1 hour and serves stale responses for up to 5 minutes while revalidating in the background.
Workers Caching follows RFC 9111
Cacheability is determined by the response headers your Worker returns. Workers Caching follows the semantics defined in RFC 9111, including heuristic freshness for responses that do not carry Cache-Control. Cloudflare's standard cache bypass conditions apply, including automatic bypass for responses with Set-Cookie header and requests with Authorization header.
Cf-Cache-Status response header values
The Cf-Cache-Status response header tells you what happened for each request. Common values include HIT (cache hit), MISS (cache miss), EXPIRED (cache entry expired), REVALIDATED (cache entry revalidated), UPDATING (cache entry updating), STALE (stale cache entry served), and BYPASS (cache bypassed).
Cache-Control no-store for authenticated responses
Authenticated responses should include the 'Cache-Control: no-store' header to prevent caching of sensitive content.
Cache-Control s-maxage header controls cache duration
The Cache API respects Cache-Control headers. The s-maxage directive controls how long a response is cached in Cloudflare's cache. For example, setting s-maxage=10 limits the cached response to 10 seconds maximum.
cf-cache-status response header
The cf-cache-status response header indicates whether a response was served from Cloudflare's cache. You can retrieve it using result.headers.get('cf-cache-status').
Cache-Control header for browser caching
Set the Cache-Control response header to control how browsers cache content separately from Cloudflare's cache. For example, response.headers.set('Cache-Control', 'max-age=1500') caches the response in browsers for 1500 seconds (25 minutes). This works independently of Cloudflare's cf options.
Default Content-Type header for static assets
A Content-Type header is attached to the response if one is provided during the asset upload process. Wrangler automatically determines the MIME type of the file based on its extension.
Default Cache-Control header for static assets
Workers attaches Cache-Control: public, max-age=0, must-revalidate by default when the request does not have an Authorization or Range header. This tells the browser that the asset can be cached but should be revalidated for freshness every time before using it. This ensures good performance while preventing stale content from being served.
ETag header for static assets
Workers automatically adds an ETag header to static asset responses. The ETag value is a hash of the static asset file. Browsers can use this header in subsequent requests with an If-None-Match header to check for freshness without re-downloading the entire file if there is a match.
CF-Cache-Status header for static assets
Workers attaches a CF-Cache-Status header to static asset responses that indicates whether the asset was served from cache (HIT) or not (MISS). Due to a technical limitation, this header may return false-positives and false-negatives, though this should be rare, so it should be considered as returning a probabilistic result.
Cloudflare may add new headers to static assets
Cloudflare reserves the right to attach new headers to static asset responses at any time in order to improve performance or harden the security of your Worker application.