Page Rules

Page Rules allow you to configure powerful traffic routing rules to your projects.

This can be used to proxy specific assets or URL paths to your own servers, implement complex redirection rules, or require authentication for sections of your site.

You can have any number of rules, the first match will win. Simply drag and drop rules to change the priority order.

If no rules match, then Quant will serve the content as per normal.

How rules are evaluated

1. Quant checks the rules in list order: the order on the Rules page, which is the rule weight order (lowest first). Disabled rules are skipped.
2. A rule matches only when all of its conditions hold: domain, country, traffic source, user agent, cookie, request method, URL and IP.
3. The first matching rule whose action ends processing produces the response. Rules below it are not checked. The most specific rule does not win; the first one does.
4. If no rule ends processing, Quant serves the project’s static content for the path, with any headers that earlier rules added.

Action	Ends processing?
Redirect, Proxy, Custom response, Serve existing static content, Execute serverless function	Yes, always
Authentication	Only when the credentials are missing or wrong (401). Correct credentials continue to the next rule
Bot challenge	Only while the visitor has not passed the challenge. A visitor who has passed continues to the next rule
Custom response headers	No. The headers are added and the next rule is checked
Execute serverless content filter	No. The filter is applied to the final response

Put specific rules above a catch-all (*) proxy or static rule: a rule below a matching proxy rule never runs. A custom response headers rule must also sit above the rule that answers the request, or its headers are not added.

Matching criteria

Domain and URL

The first part of creating a new rule is to configure a matching pattern.

It may apply to all domains attached to a project, or specific domains.

The URL match field should be a relative path (e.g /path/to/match) and is case insensitive.

• The pattern is matched against the path only. The query string is ignored, so /search also matches /search?q=term. A pattern that itself contains ? is matched against the path and the query string.
• The pattern must match the whole path: /about does not match /about/team.
• Characters other than * are literal. Regular expressions are not supported.
• A rule can list several URL patterns; any one of them can match.

Domains are either any (all domains on the project) or a list of exact host names, matched case-insensitively. List each host name; *.example.com is not treated as a wildcard.

Wildcard matches and captures

You can create complex matching patterns by using the wildcard character (*). These matches can be captured and reused in the resulting action.

With this flexibility you can create many complex rule sets, for example:

• Match content under /private/files/* and apply an authentication shield
• Match content at * and proxy the entire domain (traditional CDN)
• Match content at /api/v1/* and proxy to an API microservice (optionally enforcing cache-time on the response)
• Match content at /api/v2/* and proxy to a separate API microservice
• Match content at /views/ajax/* and proxy to a backend server at https://backend-server.domain.com/views/ajax/$1 with no cache lifetime
• Match content at /blogs/*/category/*/posts/* and redirect to /categories/$2/year/$1/$3
• Match content at multiple URL paths /blogs/* and /posts/* and proxy all traffic back to origin server at (https://backend-server.domain.com/$*)
• Detect content from VPN or cloud hosting providers and require a successful challenge response to proceed

In the above examples you can see wildcards can be used to match on part of the URLs. The resulting captures can be re-used whereby $1 refers to the first match, $2 refers the second and so on.

Note

When capturing multiple URL paths (like the /blogs/* and /posts* example above) you may not be able to reconcile to a single target.

The $* capture pattern means the entire incoming URL path will be used, useful for these instances of mapping multiple incoming URL paths to a single backend.

Wildcard and capture details:

• * matches one or more characters of any kind, including /. So /blog/* matches /blog/2024/post but not /blog or /blog/. Add /blog as a second URL pattern when the section root must match too.
• For a match on /api/* and a request for /api/v1/users, $* is /api/v1/users and $1 is v1/users (no leading slash). Captures $1 to $5 are available.
• The redirect or proxy destination is used exactly as written. Quant does not add the request path for you: a proxy address of https://origin.example.com sends every matched request to the origin’s /. Use https://origin.example.com$* to keep the path.
• The query string is added to the destination automatically, unless the URL pattern contains ?.
• A pattern without * has no $1; the text $1 is then left in the destination as is. Use $* for exact paths.

Match conditions use a mode and a list

Each of the country, traffic source, user agent, request method and IP conditions has a mode (“is one of”, “is not one of”, or any) and a list. The list is used only when the mode names it. With the mode set to any, the list is ignored, even when it has values. For example, when you manage rules through the API or Terraform, a rule with country: "any" and country_is_not: ["AU"] matches visitors from every country; set country: "country_is_not" to apply the list.

The traffic source and user agent conditions can be set in the dashboard only. The rules API and the Terraform provider do not include them. Manage a rule that needs them in the dashboard, not in Terraform.

Country matching

Use the “Country” match criteria to specify which countries the rule should apply to. You may use either the “Country is one of” or “Country is not one of” selectors to refine.

When using the geo-based matching criteria a special Vary header will automatically be emitted to ensure caching is still active on a regional basis.

Request method matching

Use the “Request method” match criteria to specify which incoming HTTP request method to apply the rule to (e.g GET vs POST requests).

You may use either the “Method is one of” or “Method is not one of” selectors to refine.

Tip

Use request method matching to apply different WAF and rate-limiting rules.

For example, POST, PUT, PATCH, DELETE requests should be scrutinized more than a GET or HEAD request, and may optionally be rate-limited to further prevent potential abuse.

Traffic source matching

Use the “Traffic source” match criteria to match on the incoming traffic source. This may be useful to tailor a response depending on where the traffic originates. Traffic sources include:

• TOR exit node
• TOR relay node
• Cloud computing services (e.g AWS, Azure, Google Cloud)
• Web security cloud providers (e.g Zscaler, Scansafe, Onavo)
• DNS proxies
• VPN services
• Web browser proxies

These traffic sources are generally less trusted and are often used in conjunction with other matching criteria to tailor a response, such as a bot challenge or denial of access.

User Agent method matching

Use the “User agent” match criteria to match on the incoming User-Agent header. This may be useful to tailor a response depending on the type of device, or to treat bots or crawlers differently to regular site traffic.

Tip

This can be useful to serve pregenerated, static content to crawlers. This can vastly improve crawl speed times when search engines index your site, especially on Javascript heavy websites. Combine this with the Quant Crawler to generate the static artifacts for a seamless solution.

Caution

There are performance implications when using this option. Caches will be fragmented by user-agent, which will reduce caching optimization by having to cache a separate copy for each type of agent.

IP Restrictions

Use the “IP restrictions” match criteria to control traffic based on individual IP addresses (e.g 200.100.20.111) or ranges (CIDR notation, e.g 202.100.20.1/16).

Caution

There are performance implications when using this option. Content cannot be cached when using IP restrictions. It is recommended to only be used for a subset of your site that requires additional security controls (for example, administrative interfaces).

Only with cookie

You may optionally control traffic flow based on the presence of a specific cookie name. This may be useful to apply different rules to authenticated vs. public traffic.

For example:

• A Drupal site may allow access to administrative pages when SSESS* cookie is present
• A WordPress site may allow access to administrative pages when wordpress_logged_in_* cookie is present
• Without this cookie present, Quant could serve entirely static traffic without touching backend servers

Actions

The action refers to the response Quant will take if the pattern matches.

Proxy

A proxy will function in the same way as a traditional CDN would, making a backend request to an origin server and serving the resulting content, optionally caching the result at the edge.

For more detail and configuration documentation, see the CDN Proxy page.

Redirect

Redirection will allow for content to redirect internally (relative) or externally (absolute).

• Redirect to: is the relative or absolute URL to redirect to. You may use captured values (e.g $1) in the redirection.
• Redirect code: is the status code to issue with the redirect (permanent or temporary).

Authentication

Authentication allows you to password protect areas of your site with basic authentication.

Custom response headers

For certain areas of your site, or based on other criteria, you may wish to inject different response headers.

These headers may be related to cacheabililty of content, security headers, or some other controls that make sense to control with more granularity.

Note

When injecting custom response headers the next rule in the chain will still fire.

The headers rule must sit above the rule that answers the request (for example the proxy rule). A header set by the rule replaces an origin header with the same name. Set-Cookie values are added, not replaced. Quant’s own response headers (such as quant-server and age) cannot be set.

Custom response

A custom response allows you to serve simple markup and set the status code.

Some example use-cases:

• Serve a custom “403 Forbidden” content response to certain geographies
• Serve a temporary “under maintenance” content response during an outage or server maintenance
• Serve a .well-known response for validating a particular content route

Serve existing static content

You may wish to serve static content from our static edge store for certain routes, or based on other criteria.

Some example use-cases:

• Serve pregenerated static content to crawlers/bots, otherwise proxy to origin
• Serve static content for specific domains or routes, otherwise proxy to origin
• Serve static content for specific geographies, HTTP methods, or any other incoming match criteria

Enter the path to the static content you wish to serve (e.g /about), or enter the special /$* value to serve static content from the same path as the incoming request.

Execute serverless function

Serverless functions are snippets of code that can execute dynamically at edge.

Enter the function UUID to trigger a serverless function based on the incoming match criteria.

Execute serverless content filter

Content filters allow dynamic code to execute over the returned response before sending to the client.

This allows you to manipulate the response prior to serving content to your end users.

Bot challenge

A bot challenge allows you to require a successful challenge response before serving content.

This is an effective measure against bots and crawlers while allowing genuine traffic to pass through with minimal friction.

There are two types of bot challenge available:

• “Checkbox” challenge - a visual challenge that must be completed before access is granted
• “Invisible” challenge - a Javascript challenge that must be completed before access is granted that does not require any user interaction

You may also configure the verification TTL (time-to-live) in seconds, after which the challenge must be completed again.

The challenge TTL is also configurable, which specifies how long a user has to complete the challenge.

Tip

Challenges are an effective measure against bots and DDoS attacks, as they slow down the traffic flow and require a higher level of coordination to bypass.

How a challenge behaves:

• A visitor who has not passed gets a 403 challenge page with Cache-Control: no-store, must-revalidate.
• A visitor who passes gets a quant_bot_verification cookie, valid for the verification TTL (default 10800 seconds). The cookie is bound to the visitor’s IP address, so a new IP address means a new challenge.
• After a pass, the next rule in the list is checked as normal.

A challenge rule with no conditions challenges every visitor. To challenge only suspicious traffic from outside your country, put both conditions on the same rule; they are combined, so both must hold:

• Traffic source “is one of” the sources you distrust (for example cloud computing services, VPN services and TOR exit nodes).
• Country “is not one of” your country (for example AU).

With the traffic source condition alone, local visitors on a VPN or a corporate cloud network are challenged too.

Error page

An error page rule (rules API type error-page) chooses the published page to show for a status code, for example a different 404 page per domain or path. It is used only when Quant builds an error response. The first matching error page rule that lists the status wins. Without one, Quant uses the _quant[STATUS_CODE] pages described in custom error pages.

Manage rules

Tool	Notes
Dashboard Rules page	Every rule type and condition; drag to reorder
Rules API	{dashboard}/api/v2/organizations/{organization}/projects/{project}/rules/{type} with Authorization: Bearer <token> (a dashboard API token with rules permissions). Types: redirect, proxy, headers, auth, custom-response, serve-static, function, content-filter, bot-challenge, error-page. GET lists and POST creates; /rules/{type}/{rule} takes GET, PATCH and DELETE
quant rules and the deploy action rules input	Function, auth function and content filter rules from a file in your repository
Terraform quant_rule_* resources and Pulumi	Rules as code

{dashboard} is https://dashboard.quantcdn.io on QuantCDN and https://dash.quantgov.cloud on QuantGov.

When you update a rule through the API:

• A PATCH changes only the fields you send.
• Each list you send replaces the stored list: url, domain, country_is, country_is_not, ip_is, ip_is_not, method_is, method_is_not. To add one URL, read the rule, add the URL, and send the complete list.
• Values inside the action settings (for example the headers map of a headers rule) are merged with the stored values, so a PATCH cannot remove an entry there. Delete the rule and create it again.
• A 409 response means another change to the project’s rules is in progress, or the rule is managed by quant rules. Retry after a few seconds, or change the rules file.
• weight must be 0 or more. A new rule without a weight is added at the end of the list.

In a quant rules file, type: auth runs an auth function. In the rules API and Terraform, auth is basic authentication.

Test a rule change

• A rule change is not instant. Allow a few minutes before you judge the result.

• A response already in the cache is served without checking the rules again, and a rule change does not purge the cache. Test with a cache-busting query string, which does not change which rule matches:

  curl -sI "https://www.example.com/old-page?cb=$RANDOM"

• Or purge the affected paths.

Configure

Caution

Incorrect configuration can make your site inaccessible. It is recommended you trial Page Rules on a non-production project before applying.