HTTP Zones (also known as Cache Rules) use a simple wildcard format to alter behavior and caching of specific locations and file extensions. The wildcard character of * and | character can be used to supply multiple options for a rule. See the examples below for more information.

Configure a zone

  1. Open Services, choose the service's Action → Ports, then the HTTP/HTTPS port's Action → Zones.
  2. Choose Add Zone, enter a Location expression such as /assets/*, select Cache, and Save. Use Action → Move Up to place specific rules before broader matches, then reload to confirm the order.
Saved asset and image cache rules in evaluation order
Rules are evaluated from top to bottom. The asset rule is saved above the default image rule.

Open that rule's Action → Advanced Config. For static assets, an example is Cache Time 30 minutes with Request Cache-Control → Allow and Cache different results for different query strings enabled. Choose Update, then reopen Advanced Config to verify the saved settings.

Saved cache lifetime and cache-key options for static assets
Use separate query-string cache entries when query parameters change the response.

Advanced Config also controls response status codes to cache, separate HTTP/HTTPS cache entries, optional response expiry headers, redirection and per-zone rate limits. Keep personalized or authenticated responses out of shared caching; do not use Force to work around private response headers. Saved settings do not prove that a response is cacheable: check the live response and cache data after deployment.

Examples:

RuleDescriptionMatches
/abc/*Matches a static file directory or path component"/abc/", "/abc/1.html"
*.cssMatches an extension of css"/a/main.css", "/main.css"
/style/*.cssMatches an extension of css within the directory of style"/style/main.css", "/style/2/main.css"
/abc.htmlMatches /abc.html exactlyonly "/abc.html"
*.css|*.jsMatches an extension of css or js"/a/main.css", "/app.js"
type:imagesMatches images. Valid types include: images, resources, documents and sound"image.png", "image.jpg"

Pre-defined Types

We supply a set of pre-existing cache categories that can be applied over many filetypes (using the type:<typename> syntax). These are as follows:

  • images: Matches .jpg, .jpeg, .gif, .ico, .png, .bmp, .pict, .tif, .tiff, .svg, .svgz
  • sound: Matches .midi, .mid, .pls, .mp3, .wav
  • documents: Matches .csv, .doc, .pdf, .ppt, .eps, .docx, .xlsx, .xls, .pptx, .ps
  • resources: Matches .css, .js, .swf, .ttf, .eot, .woff, .ejs, .class, .jar, .otf, .webp

A new HTTP/HTTPS port starts with a type:images rule using the Cache policy. This initial rule enables image caching subject to the cache conditions below. You can edit or remove it; it is separate from the no-match fallback.

Have we missed your favorite filetype? You can define custom rules using the wildcard format.

Cache conditions

There are three conditions that determine if a request is to be stored into the cache.

  1. If the file is over 10mb, it will not be cached.
  2. The headers are checked to ensure the content requested is cacheable
  3. There is no content adjusting mitigation event occurring on this request

The cache is not for storing large files, each service is limited at 100mb. Data is expired on a Least Recently Used basis in addition to the Expiration time.

Cache Policies

The following cache policies are available:

  • Cache: Caching is enabled by this rule (default for cache rules)
  • No Cache: Never cache this resource (called Disabled in the Zones list; also the no-match fallback policy)
  • Force: Caching is enabled for nearly all requests (regardless of headers)
  • Fallback: Serving from cache is only enabled when the backend is offline

In Cache mode Cache-Control and Expires headers are honored. Specifically:

  • Cache-Control: private skips storage into the cache
  • Cache-Control: no-store skips storage into the cache
  • Cache-Control: no-cache skips storage into the cache
  • Cache-Control: max-age=0 skips storage into the cache
  • Expires: <past-date> skips storage into the cache

If no configured rule matches, the fallback is No Cache, equivalent to a final * rule with that policy. On a new port, the initial type:images rule is evaluated before this fallback, so matching images are eligible for caching while unmatched requests are not cached. Removing the image rule leaves those requests subject to the same fallback unless another rule matches. Exceptions exist for very specific requests like favicons and robots.txt files under specific cases.

Headers

The cache honors the backend’s Expires, Cache-Control: no-cache, and Cache-Control: max-age=XXX headers.

The following response headers flag a response as uncachable:

  • Set-Cookie
  • Cache-Control containing no-cache, no-store, private, or a max-age with a non-numeric or 0 value
  • Expires with a time in the past
  • X-Accel-Expires: 0

Redirection

It is optionally possible to define a redirect for a matching HTTP Zone. In this situation any caching settings will not take effect.

Redirection URLs may contain the following variables:

  • $scheme - The requested scheme (e.g "http" or "https")
  • $host - The requested domain name
  • $uri - The normalized path of the current request, including the leading slash, without query parameters
  • $request_uri - The original request path, including the leading slash and query string

To redirect this zone to HTTPS while preserving the original path and query string, use https://$host$request_uri?. For example, http://example.com/search?q=test redirects to https://example.com/search?q=test.

Zone redirects automatically append the incoming query string. The final ? in this zone example suppresses that automatic append because $request_uri already includes the query string; the final ? is not sent to the client. Without it, query parameters would be duplicated. A zone target using $uri also receives the appended query string, but uses the normalized path.

The REDIR port backend instead uses the target as supplied: use https://$host$request_uri there, without the final ?.

Additional Notes

  • HTTP Zones paths can contain spaces and other special characters.
  • Duplicate slashes in paths (e.g aa//bb) will be combined into a single slash (e.g aa/bb). HTTP Zones can't match duplicate forward slashes in url (like most browsers).