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.

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.

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.

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.

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.

Configure

Caution

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