HTTP Headers

To make use of Accelerated Domains, you need headers set in the application to let the Accelerated Domains cache engine know what to cache and not, and the Cache TTL (time-to-live).

Headers that needs to be set by origin

x-acd-cms

String value with the cms name, for controlling cms specific features in Accelerated Domains. Please note that this header might not be visible as response headers by the requesting client. Accepted values: wordpress,craft,magento,drupal,laravel, and custom

Cache Controling Headers

Accelerated Domains supports a set of various cache controling headers. These are read in a prioritized order:

1. CDN-Cache-Control
2. Cache-Control
3. X-ACD-TTL

CDN-Cache-Control

We highly recommend setting the CDN specific CDN-Cache-Control header. Accelerated Domains reads the CDN-Cache-Control header first, and it has the highest priority. If the CDN-Cache-Control header is set, the other cache controling headers are not read or respected.

Cache-Control

We highly recommend setting a cache control header on HTML responses. Specifically setting max-age (cache TTL for private caches, i.e browser cache). If this is not set, we set the value in Accelerated Domains when we read the HTTP headers sent by the origin.

s-maxage (cache TTL for shared caches) is not required, as this will be overwritten by the x-acd-ttl value, but we recommend setting the value to 600 (10 minutes) in case there are scenarios with shared caches between Accelerated Domains and the origin.

On pages that should not be cached, both max-age and s-maxage should be set to 0.

Origin-Cache-Control

Accelerated Domains alters and sets it's own Cache-Control headers, so to be able to see the Cache-Control header sent by the origin we move the value of the Cache-Control header sent by the origin to a new header named Origin-Cache-Control for easier debugging.

X-ACD-TTL (legacy)

Integer value for how many seconds the content should be cached by Accelerated Domains. Can also be string no-cache if the response should not be cached. Recommended value on cachable pages: 86000 (24 hours – 400 seconds)

Headers set by Accelerated Domains

x-acd-status is present if the requests has gone through our Accelerated Domains HTML optimization worker. The status header can have multiple values, and also provides minimal debugging information.

Values	Description
HIT	Cache is hit, and response is served from cache.
no-cache	Cache is bypassed.
HIT, no-store, [reason]	Cache is hit, and response is served from cache. However, the request will not be stored in cache. Reason is that the request, if it hits origin, might respond with a non-unique response (i.e cart content in header carts etc).Reason for no-store is also present. Currently will always be cookie as this is the only thing that trigger a no-store.Happens if woocommercecart* cookie is present, but the request can be served from cache.
BYPASS, [reason]	Worker is bypassed. Reason is included.
MISS	Cache is missed. The request should fill the cache, and the next request should be a HIT.
config-missing	The plugin does not seem to be installed or/and we do not get the correct headers.

Reasons

A reason for the behaviour might be sent through the x-acd-status header. These reasons includes:

Reason	Explaination
cookie	The request has a cookie present that is in our list of cookies that should trigger a bypass. i.e nocache or wordpress_logged_in*
url	The request is to a url which is set to be bypassed in our worker. i.e cart or checkout.
set-cookie	The response from server includes a set-cookie header, making the response unique and therefore impossible to cache safely.
private	The response from server includes a cache-control header which sets the response as private. A private response cannot be cached.