Request Caching

We rely on caching to reduce the burden on both our bandwidth and upstream servers. Depending on the service or client request, we may retrieve content from our managed cache rather than performing a live request to a server. In most cases, this should be unnoticeable, but upstream server misconfigurations or modifying previously-published resources tend to cause the most issues.

Platform Tiers

In general, we segment traffic based on the following tiers.

Cache Disabled

A request will always be sent to the upstream server.

Standard Cache

Follows conventional caching server behaviors described by RFC 9111.

Caching directives from downstream requests which affect cache selection may not be respected.

Managed Browser Cache

Publisher Hints

The standard HTTP caching conventions play an important part as traffic passes through our network.

When serving content and files from servers, be sure to include the following response headers, where appropriate: Cache-Control, ETag, Last-Modified, and Vary.

When we find a stale cache entry, we may perform revalidation requests. Where appropriate, be sure to respond with 304 Not Modified responses based on If-Modified-Since and If-None-Match request headers.

Debugger Hints

Responses delivered from our managed cache will generally include some additional metadata that can be used for debugging. Client and runtime implementations must not rely on the presence of this information.

• Age indicates the number of seconds the response has been cached. This may include additional time if the content was cached be other upstream intermediaries, such as CDNs.
• Namedgraph-Cache indicates an applied caching tier, cache status, and correlation identifier.

Most services provide artifacts, such as the following, which include this information to aid in debugging.

• Web Archive (WARC) will include response headers provided by any upstream servers, including caching servers.