Edge rules in Sitefinity Cloud
Overview
Sitefinity Cloud provides a custom edge rules engine that runs at the CDN layer, before traffic reaches the origin server. Edge rules allow per-project configuration of request and response transformations based on a flexible set of conditions and actions. They are processed by Cloudflare Workers at the edge, which ensures low latency and no impact on origin performance.
Edge rules are managed by Progress on behalf of the customer. To request a new edge rule or modification of an existing one, see Request edge rules.
How edge rules work in Sitefinity Cloud
Edge rules are evaluated in two phases:
- Request phase - Rules are matched against the incoming request before it is forwarded to the origin. Actions in this phase can redirect the visitor, rewrite the request URL, override the origin server, or modify the request headers.
- Response phase - Rules are matched against the response received from the origin. Actions in this phase can override cache behavior, add custom response headers, or apply redirects based on response status codes.
Edge rules are evaluated in order. If multiple rules match, their actions are applied sequentially.
Conditions
Each rule can define one or more conditions that must all be satisfied for the rule to match. The following condition types are available:
| Condition | Description |
|---|---|
| URL pattern | Matches the full request URL against a regular expression. |
| URL component patterns | Matches against specific URL components such as hostname, pathname, or query string. |
| Response status code | Matches the HTTP response status code (response phase only). |
| Environment name | Matches the Sitefinity Cloud environment name (for example, Staging or Production). |
| Client IP | Matches the visitor IP address against an allowlist or blocklist. Supports IPv4 with CIDR notation and IPv6. |
| Request headers | Matches one or more request header values against patterns. |
| Cookies | Matches cookie values, with optional Base64 decoding. |
When multiple conditions are specified on a single rule, all conditions must match for the rule to apply (logical AND).
Actions
Request phase actions
| Action | Description |
|---|---|
| Redirect | Sends an HTTP redirect response (301 or 302) to the visitor with a destination URL derived from the request URL using a pattern replacement. |
| URL transform | Performs a regex-based URL transformation that results in a redirect to the transformed URL. |
| URL rewrite | Internally rewrites the request URL before forwarding to the origin. The visitor does not see the rewrite. |
| Origin override | Forwards the request to a different origin server than the default. |
| Custom request headers | Appends or overrides headers on the request sent to the origin. |
| Custom request query parameters | Appends query parameters to the origin request URL. |
| Cache bypass | Prevents the response from being cached on the CDN, regardless of response headers. |
| Mandatory cache duration | Overrides the CDN cache duration for responses matching the rule. |
Response phase actions
| Action | Description |
|---|---|
| Redirect | Sends an HTTP redirect response based on the origin response (for example, redirect on a specific status code). |
| Custom response headers | Adds or overrides headers on the response sent to the visitor. |
| Cache bypass | Prevents the response from being cached on the CDN. |
| Mandatory cache duration | Sets a specific CDN cache duration for the response, overriding the default behavior. |
Interaction with CDN caching
Edge rules interact with the default CDN caching behavior described in Performance, and their actions can take precedence:
- A cache bypass action prevents the CDN from caching the response.
- A mandatory cache duration action overrides the default cache duration. As with the built-in status-code-based rules, it sets a minimum cache duration and if the origin specifies a longer duration, the longer value is respected.
- Response phase cache actions take precedence over request phase cache actions when both are present.
- Edge rule cache actions take precedence over the default status-code-based caching rules.
Origin fallback
Edge rules support configuring a fallback origin. When the primary origin returns a response with specific status code that matches a configured pattern, the request is automatically retried against a fallback origin. This enables scenarios such as:
- Serving content from a secondary application when the primary application does not return the requested content
- Falling back to a static site when the main application is unavailable for specific paths
Common use cases
- Redirect legacy URLs - Redirect requests from old URL patterns to new ones at the edge, without requiring changes to the application.
- IP-based access control - Restrict access to specific environments (for example, Staging) based on visitor IP address.
- Custom origin routing - Route specific URL paths to a different backend application or static file storage.
- Header injection - Add custom headers to requests or responses for integration with third-party services.
- Environment-specific behavior - Apply different caching or routing rules per environment (Staging vs Production).
- Cache optimization - Enforce specific cache durations for resource types for which the application does not set appropriate cache headers.
Request edge rules
To request a new edge rule or to modify an existing one:
- Log a support case.
- Describe the desired goal and the expected behavior.
- Specify which environments the rule should apply to.
- Sitefinity Support team will consult on the best approach, configure the appropriate rule, and deploy it.
NOTE: Edge rules are deployed globally across the CDN edge network. Changes take effect within seconds of deployment.