Static implementation guide
Caching External Rewrites
Understand how a public gateway can cache rewritten origin responses while preserving one visible hostname for documents and assets.
Last updated 2026-08-21
The gateway and origin lifecycle
An external rewrite keeps the browser on the gateway URL while the gateway obtains a response from another origin. On a cold request, both projects can participate in the lifecycle. Once the gateway cache is warm, a reusable response can be served near the visitor without repeating the origin request. This distinction is the center of the experiment: client request count may remain constant while origin activity falls.
Caching must be explicit enough to compare deployments. The enable flag controls whether rewritten responses are eligible, while a CDN-specific cache directive states freshness and stale behavior. Diagnostic headers identify which configuration and origin produced the response without changing the document body.
Measure without disturbing the cache
Send sequential requests to one stable URL with no cookies, authorization, or changing query parameters. Record status, cache state, point-of-presence identifier, age, response bytes, and latency for every attempt. Browser hard reloads often add no-cache directives, so they are poor evidence for a clean warm-cache sequence.
Run the disabled and enabled experiments with matching request counts, location, URL, and time windows. A successful enabled run should show warm hits and substantially fewer requests reaching the origin. Dashboard totals can arrive late and may attribute transfer differently across projects, so preserve raw probe output alongside the final usage table.