Caching and response headers

Headers reveal which layer answered and how downstream caches may treat the response. Static HTML stores the document body, not a serialized replay of every header produced during the original WordPress render.

Headers from an early PHP hit

When the drop-in serves index.html, POM Cache sends:

HTTP status: 200
Content-Type: text/html; charset={WordPress site charset}
Content-Length: {file size}
X-POM-Cache: Served static cache from PHP; phase=early

Content-Length is sent when the filesystem reports a size. For HEAD, the response has the headers but POM Cache does not read the file body.

The X-POM-Cache value is diagnostic. It does not define browser or CDN freshness.

Headers from Apache

Direct Apache delivery happens without PHP, so it does not add the POM Cache PHP hit header. The supplied rewrite block sets UTF-8 as the default character set, while the rest of the response behavior follows the effective Apache, virtual-host, proxy, and CDN configuration.

Do not treat the absence of X-POM-Cache as proof of a miss. Use the unchanged generation comment, server logs, or an approved origin trace.

Headers while WordPress renders

For a normal dynamic frontend render where its output buffer starts, POM Cache sends:

Vary: Cookie

This advertises that cookie state can affect the dynamic representation. A deployment can override or suppress that value with the POM_CACHE_VARY_HEADER configuration constant.

Changing Vary affects upstream cache behavior and cache-key cardinality. Coordinate it with the CDN configuration instead of treating it as a cosmetic header.

What POM Cache does not set for static HTML

The HTML runtime does not define a built-in age-based Cache-Control policy and does not create Brotli/Gzip variants. Browser lifetime, shared edge lifetime, revalidation, and content encoding belong to the web server or CDN.

This differs from the independent Progressive JSON cache, which has a configurable JSON Cache-Control value. Do not copy JSON header expectations to HTML.

Original WordPress headers are not stored in index.html

Suppose the first dynamic render adds a custom PHP header. The HTML body may be cached, but that header is not embedded as response metadata in the file. A later Apache or early PHP hit will only have headers supplied by that delivery path.

If a public header is required on every cached response—security policy, CDN hint, language metadata, or another invariant—configure it at a layer that runs for static files, usually the web server or CDN.

Headers that contain per-user, per-request, or secret data are evidence that the response should not be shared.

CDN headers describe a different cache

Services may add Age, Via, X-Cache, or vendor-specific values. Interpret them separately:

• CDN hit → edge object was reused;
• X-POM-Cache ... phase=early → origin PHP reused POM Cache HTML;
• neither → could be Apache direct delivery or a dynamic render.

Trace from the outermost layer inward and avoid using one vendor header as evidence for another layer.

Inspect a response

With a browser’s network panel or an approved command-line client:

1. record the final URL and status;
2. inspect Content-Type, Content-Length, Vary, Cache-Control, Age, and cache diagnostics;
3. repeat after an origin purge;
4. repeat after edge invalidation;
5. compare anonymous and authenticated requests;
6. send HEAD and confirm there is no body;
7. confirm non-HTML Accept requests never receive the page file.

Do not share authorization, Cookie, or Set-Cookie values in support logs.

Continue with Verify a cache hit for a layer-by-layer check.