Managing your CIS deployment for optimal reliability

Setting up Serve Stale Content

To enable Serve Stale Content, follow these steps:

1. Use the navigation menu to select Page Rules under Performance.
2. Create a page rule with the URL pattern of your domain.
3. Add the Serve Stale Content setting with the toggle on.
4. Select Provision Resource.

Serve Stale Content limitations

• Serve Stale Content caches the first 10 links from your root HTML, then just the first links from each of those pages, and finally the first links from each of those subsequent pages. This means that only some pages on your site are viewable when your origin server goes down.

• Recently added sites don't have a large cache of their site available, which means that Serve Stale Content might not work if you only added the site a few days ago.

• CIS does not show private content or handle form submission (POSTs) if your server is down. Visitors are shown an error on checkout page or items require a login to view.

• To trigger Serve Stale Content, your web server must be returning a standard HTTP Error code of 502 or 504 timeout. Serve Stale Content also works when we encounter issues contacting your origin (Errors 521 & 523), timeouts (522 & 524), SSL errors (525 & 526) or an unknown error (520). Serve Stale Content is not triggered for other HTTP response codes, such as 404s, 500, 503, database connection errors, internal server error, or empty replies from server.

• Serve Stale Content does not work if a "Cache Everything" page rule is enabled with the "Edge Cache Expire TTL" lower than the caching frequency, because the "Edge Cache Expire TTL" causes the Serve Stale Content cache to be purged in the corresponding interval.

Setting up Origin Cache Control

To enable Origin Cache Control, follow these steps:

1. Use the navigation menu to select Page Rules under Performance.
2. Create a page rule with the URL pattern that references your domain.
3. Add the Origin Cache Control setting with the toggle on.
4. Select Provision Resource.

Page Rule precedence

Two specific page rules take precedence for caching overall:

• If a page rule has Cache Level set to Bypass, the resources that match that page rule are not cached. CIS still acts as a proxy, and our other performance features remain active. However, your content is fetched from your origin server directly, instead of served from our cache.

• If a page rule has Cache Level set to Cache everything, resources that match the page rule are cached. Using this page rule setting is the only way to tell us to cache resources beyond what we consider static, including HTML.

If no page rule is set, we use the Standard caching mode, which is based the extension of the resource. We cache static resources only.

Origin cache-control headers

The second way to alter what CIS caches is through caching headers sent from the origin. CIS respects these settings, but you can override them by specifying an Edge Cache TTL page rule setting. Here are the headers we consider when deciding what resources to cache from your origin:

• If the Cache-Control header is set to private, no-store, no-cache, or max-age=0, or if there is a cookie in the response, then CIS does not cache the resource. Note that sensitive material should not be cached, so you might consider using one of these headers in that case.

• If the Cache-Control header is set to public and the max-age is greater than 0, or if the Expires headers are set any time in the future, the resource is cached.

According to RFC rules, Cache-Control: max-age trumps Expires headers. If both are seen and they do not agree, max-age wins.

Using the s-maxage header

The third way to control caching behavior and browser caching behavior together is by using the s-maxage Cache-Control header.

Normally we respect the max-age directive:

Cache-Control: max-age=1000

But if you want to specify a cache timeout that's different from the browser, we can use s-maxage. Here's an example that tells CIS to cache the object for 200 seconds and the browser to cache the object for 60 seconds.

Cache-Control: s-maxage=200, max-age=60

Basically s-maxage is intended to be followed ONLY by reverse proxies (so the browser should ignore it) whilst on the other hand we (CIS) give priority to s-maxage if it is present. We respect whichever value is higher: the browser cache setting or the max-age header.

Summary on cache control headers and page rules for reliability

To sum up, here are some main areas to consider for reliability with regard to caching:

• Check your origin's caching headers to make sure there are no overriding headers for cacheable resources (Cache-Control and Expires).

• CIS always caches static content by default, with the following TTL depending on the return code:

  200 301    120m;
  302 303    20m;
  403        5m; for reliability
  404        5m;
  any        0s;
  

• To cache more, create a Page Rule with Cache Level set to Cache everything on the URL (if your web server returns a 404 when requesting this URL, this result is cached for 5m only).

• To avoid caching on a URL, create a page rule with Cache Level set to Bypass.

Setting up a forwarding URL

To enable Forwarding URL, follow these steps:

1. Use the navigation menu to select Page Rules under Performance.
2. Create a page rule with the URL pattern that references your domain.
3. Add the Forwarding URL setting.
4. Select the forwarding type and enter the destination URL.
5. Select Provision Resource.

Forwarding URL examples

Imagine that you want to make it easy for anyone coming to reach a URL such as:

*www.example.com/+

*example.com/+

This pattern matches:

http://example.com/+
http://www.example.com/+
https://www.example.com/+
https://blog.example.com/+
https://www.blog.example.com/+

It does not match:

http://www.example.com/blog/+  [extra directory before the +]
http://www.example.com+  [no trailing slash]

After you've created the pattern that matches what you want, add the Forwarding URL setting and select the forwarding type and enter the destination URL. For example:

https://plus.google.com/yourid

Select Provision Resource. Within a few seconds any requests that match the pattern are forwarded to the new URL with the specified redirect.

Advanced forwarding options

If you use a basic redirect, such as forwarding the root domain to www.yourdomain.com, you lose anything else in the URL. For example, you could set up the pattern:

example.com

And have it forward to:

http://www.example.com

But then if someone entered:

example.com/some-particular-page.html

Then they are redirected to:

www.example.com

instead of:

www.example.com/some-particular-page.html

The solution is to use variables. Each wildcard corresponds to a variable that can be referenced in the forwarding address. The variables are represented by a $ followed by a number. To refer to the first wildcard you'd use $1, to refer to the second wildcard you'd use $2, and so on. To fix the forwarding from the root to www in the previous example, use the same pattern:

example.com/*

Then set up the following URL for traffic to forward to:

http://www.example.com/$1

In this case, if someone went to:

example.com/some-particular-page.html

They are redirected to:

http://www.example.com/some-particular-page.html