Please try again later.
" } } ] } } } } ``` ### Response Status Code Match Condition A new response match condition that allows rules to match based on the HTTP response status code. Supports multiple matching formats for flexible status code targeting. - **`status`**: Matches when the response status code is in the provided list - **`!status`**: Matches when the response status code is **not** in the provided list - Supports three value formats: - **Integer**: Exact status code (e.g., `500`) - **Range string**: Inclusive range (e.g., `"502-504"`) - **Class string**: Status code class (e.g., `"4xx"`, `"5xx"`) - Up to 100 values per condition **Example**: Match specific error status codes: ```json { "onClientResponse": { "features": { "respondWith": { "rules": [ { "matchAll": { "status": [502, 503, 504] }, "args": { "status": 503, "body": "Upstream error — please retry." } } ] } } } } ``` **Example**: Match a class of status codes: ```json { "onClientResponse": { "features": { "setHeaders": { "X-Error-Page": { "rules": [ { "matchAll": { "status": ["5xx"] }, "args": { "value": "true" } } ] } } } } } ``` ### Geographic Match Conditions New geographic match conditions have been added to provide more granular location-based routing capabilities: - **`continent`** / **`geo_continent`**: Match requests from specific continents using Edgescape continent codes (AF, AS, EU, NA, OC, SA, OT) - **`region`** / **`geo_region`**: Match requests from specific regions using Edgescape region codes - **`city`** / **`geo_city`**: Match requests from specific cities using Edgescape city codes Each condition supports both a prefixed (`geo_*`) and non-prefixed version as aliases, allowing for flexible configuration syntax. For match conditions, both versions work identically. However, for variable interpolation, always use the non-prefixed version (e.g., `{{continent}}`, `{{region}}`, `{{city}}`). **Example**: Route traffic based on continent: ```json { "onClientRequest": { "features": { "route": { "rules": [ { "matchAll": { "continent": ["EU"] }, "pm_variables": { "RT_ORIGIN_HOST_HEADER": "eu-origin.mysite.com", "RT_ORIGIN_DNS": "eu-origin.example.com", }, "args": { "originId": "default_eaas" } }, { "matchAll": { "continent": ["AS"] }, "pm_variables": { "RT_ORIGIN_HOST_HEADER": "asia-origin.mysite.com", "RT_ORIGIN_DNS": "asia-origin.example.com", }, "args": { "originId": "default_eaas" } } ] } } } } ``` **Example**: Custom response for specific city: ```json { "onClientRequest": { "features": { "respondWith": { "rules": [ { "matchAll": { "city": ["SEATTLE"] }, "args": { "status": 200, "body": "Welcome from {{city}}, {{region}}!" } } ] } } } } ``` ### GRN Interpolation Variable A new Global Request Number (GRN) interpolation variable has been added for tracking and debugging purposes: - **`{{grn}}`**: Inserts the unique Global Request Number assigned to each request This can be used in custom headers, response bodies, or redirect URLs to track requests across the CDN edge and origin infrastructure. **Example**: Add GRN to response header for debugging: ```json { "onClientResponse": { "features": { "setHeaders": { "X-Request-ID": "{{grn}}" } } } } ``` **Example**: Include GRN in custom error page: ```json { "onClientResponse": { "features": { "respondWith": { "rules": [ { "matchAll": { "status": ["5xx"] }, "args": { "status": 503, "body": "Request ID: {{grn}}
" } } ] } } } } ``` --- ## New Features -> Delivery Configuration ### respondWith on onClientResponse The `respondWith` feature is now available in the `onClientResponse` event handler. This allows you to construct custom responses at the edge based on response match conditions, such as origin timeout or status code. This is particularly powerful when combined with the new `origin_timeout` and `status` match conditions to serve custom error pages or fallback responses. **Example**: Custom error page for server errors: ```json { "onClientResponse": { "features": { "respondWith": { "rules": [ { "matchAll": { "status": ["5xx"] }, "args": { "status": 503, "headers": { "Content-Type": ["text/html"], "Cache-Control": ["no-store"] }, "body": "We are working on it.
" } } ] } } } } ``` --- ## Deprecations ### http2 and http3 Features The `http2` and `http3` features under `onClientRequest.features` are now **deprecated**. These transport protocol settings are managed at the platform level and no longer need to be configured per-tenant. Existing configurations using `http2` or `http3` will continue to function, but these fields may be removed in a future release. No migration action is required at this time. --- ## Schema Changes - Added `origin_timeout` and `!origin_timeout` properties to `match_condition_response` - Added `status` and `!status` properties to `match_condition_response` (supports integer, range, and class formats) - Added `respondWith` feature to `onClientResponse` event handler - Added `continent` / `geo_continent` geographic match conditions - Added `region` / `geo_region` geographic match conditions - Added `city` / `geo_city` geographic match conditions - Added `{{grn}}` interpolation variable for Global Request Number - Marked `http2` feature as deprecated - Marked `http3` feature as deprecated - Updated `chunkedTransferEncoding` description (removed `http2` reference) --- ## Migration Guide ### Recommended Actions #### 1. Remove http2/http3 Configuration If you are currently setting `http2` or `http3` in your tenant configuration, these are now deprecated. The updated template (v1.11.0) adds http/2 and http/3 to the default rule. ```json // Before { "features": { "http2": true, "http3": true } } // After — remove these fields { "features": {} } ``` ## Resources - [Delivery Configuration Documentation](/tenant-schemas/delivery-config) - [Match Conditions Documentation](/tenant-schemas/match-conditions) - [Security Configuration Documentation](/tenant-schemas/security-config) - [Configuration Examples](/examples) - [Tenant Schema (JSON)](/tenant-schema.json) --- Questions or feedback? Please refer to the documentation or contact support.