Google SXG cache
The Google SXG cache sets these requirements in addition to the ones set by the SXG spec:
- The SXG must have a freshness lifetime of at least 120 seconds, as computed for a shared cache from its outer headers.
- The signed
fallback URLmust approximately equal the URL at which the SXG was served. Where possible, aim to make them byte-equal. The set of allowed differences is not precisely specified, but approximately:
- Characters may be substituted by their percent encodings, and vice versa, with the exception of meaningful delimiters like
- Query parameters may be re-ordered.
- Valueless query parameters may be encoded with or without a trailing
&s in the query string are allowed.
- The signed
- The signature header must contain only:
- One parameterised identifier.
- Parameter values of type string, binary, or identifier.
- The payload must be non-empty.
- The signed
cache-controlheader cannot have a
privatedirective, even with a value (e.g.
content-typemust satisfy the
linkheader, if present, must lead to successful substitution per the Loading spec. Specifically, it must meet these requirements, in addition to the ones set by the Link spec:
URI-Referencemust be an absolute
- Parameter names can only be
relparameters must be either
imagesrcsetvalues must parse as a srcset attribute.
- There may be no more than 20
crossoriginvalues must either be the empty string, or
rel=preloadmust have a corresponding
rel=allowed-alt-sxgwith the same URI, which in turn must contain a
header-integrityparameter with a value that satisfies the CSP
hash-sourcegrammar using the
- The preloaded URLs, when requested with an SXG-preferring
Acceptheader, must respond with valid SXGs that match their given
linkheader must not be present on subresources, i.e. SXGs that are themselves preloaded from other SXGs.
- There must not be a signed
- The signature’s lifetime (
expiresminutes request time) must be >= 120 seconds.
- The SXG must be no larger than 8 megabytes.
- The page should be responsive, i.e. correct on all media. (In the future, a supported-media annotation should allow this constraint to be removed.)
Some of the above limitations are overly strict for an SXG cache’s needs, and were implemented as such for the sake of expediency. They may be loosened over time, especially in response to publisher feedback.
4.2.1. Calculating Freshness Lifetime A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of the following:
- If the cache is shared and the s-maxage response directive (Section 184.108.40.206) is present, use its value, or
- If the max-age response directive (Section 220.127.116.11) is present, use its value, or
- If the Expires response header field (Section 5.3) is present, use its value minus the value of the Date response header field, or
- Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see Section 4.2.2.
Not sure if CF follows this, but that would mean in order of priority would be cache-control s-maxage, max-age, expires? Looks like cdn-cache-control header isn’t supported then.