Marfeel Docs

# Cache headers

The following headers can be found in requests to Marfeel pages, adding valuable information that will help with troubleshooting.

You can explore those headers either in Chrome Network Activity tab (opens new window) or by running curl -I https://yourfavouritetenant.com/ in the terminal.

# Check if MarfeelCDN is active

The MRF-tech: CDN header shows if MarfeelCDN is active. Otherwise, it's not present.

# Cache status

The mrf-cache-status header indicates the status of the cache at different layers. It uses letters (M,H,S,R) in "X-XX" format. e.g. mrf-cache-status: R-RH

  • The first letter refers to the cache-status of M-shield (mobile requests only);
  • The second letter represents the cache-status of Fastly Shield;
  • The third letter represents the cache-status of Fastly Edge;

Each letter has a meaning representing the cache status on that layer

M → MISS, when the resource was not found and triggered a fetch to the next layer

H → HIT, means that the resource was cached in the PoP and therefore served directly without the need to fetch content from the next layer.

S → STALE, when the resource's TTL was expired but that was still valid to be delivered (following stale-while-revalidate or stale-if-error headers)

R → REFRESHING, when a stale response has been delivered to a user, inner cache layers are instructed to refresh the content from origin instead of delivering another stale response. This instruction comes from header background-fetch="1", added by the layer which responded with a stale version.

WARNING

The response header from the previous layer is part of the cache of an object. For example, a resource answering with M-MH does not mean that only Fastly Edge has the resource cached. It only gives historical information: when Fastly Edge cached the resource, the shields didn't have it in their cache. At the time the resource is requested, and answers with M-MH, it is highly likely that the resource has already been cached in both shields, and that Fastly Edge simply doesn't know about it, as it relies on its own cached version of the resource.

# Content type

content-type has information about the format of the content. e.g. content-type: text/html;charset=UTF-8

# Status

status contains information about the HTTP response code (opens new window). e.g. status: 404

# Which POP served the content

x-served-by header indicates which Point of Presence fetched the request. The last three letters of its value refer to the closest Airport to the PoP. e.g. A content with this header x-served-by: cache-mad22045-MAD was served from a PoP in Madrid.

# Last modification

The x-mrf-lastmod header indicates when was the last time the content was invalidated. Shown in Unix timestamp.

WARNING

Gutenberg adds this header: it only appears on marfeelized content that goes through our server.

# Fastly tracer ID

x-b3-traceId is a unique identifier added by Fastly to keep track of every request.

TIP

Searching those requests in Kibana (opens new window) is a helpful resource for debugging.

# Primal ID

x-b3-traceId-primal is a unique identifier set by Gutenberg on rendering. Its value is the x-b3-traceId of the original request for specific content, can be used to track the request that originated new content.

# Cache control

cache-control contains information to determine the TTL of each content. e.g. cache-control: public, max-age=61, stale-if-error=2592000

The Marfeel standards determine the following:

  • For files with extension CSS, JS, GIF, PNG, JPG, JPEG, WEBP, WOFF, TTF, ICO or SVG Marfeel applies the default max-age for static resources. (86400s)

  • For files with extension that is not CSS, JS, GIF, PNG, JPG, JPEG, WEBP, WOFF, TTF, ICO or SVG, Marfeel respects the tenant's max-age value as long as it's between the minimum and maximum allowed. (minimum: 60s, maximum: 86400s)

  • If there's no max-age, we apply the minimum. (60s)

# Public/private

The first value of cache-control determines if the content should be cached or not.

  • If private it's not cached.
  • If public it's cached.

# max-age

Determines the maximum time a layer of cache can keep the content. Once expired, the first request for that content will return a stale version while the fresh version is requested to the origin server.

This value can be customized for each tenant.

# stale-if-error

Strategy to keep the content in the cache for a long time (1 month by default).

This configuration allows cache layers to serve stale content when there's an error on the origin servers(404,5xx...) to guarantee that the end-user gets content.

For example Cache-Control: stale-if-error=1200 will allow stale content to be served for up to 20 minutes after its TTL has expired.

# stale-while-revalidate

Strategy to refresh the content on the background when stale content is served.

This configuration enables the client to accept stale responses for the time indicated while asynchronously on the background, a fresh version is retrieved.

For example Cache-Control: stale-while-revalidate=900 will allow stale content to be served for up to 15 minutes after its TTL has expired and whenever this happens, it will trigger the process to refresh that content.

← MarfeelCDN active →