Skip to main content

Release 1.11.0

Release Date: February 9, 2026

info

This release adds new response match conditions for origin timeout detection and status code matching, introduces respondWith support in the onClientResponse event handler, deprecates the http2 and http3 features, adds support for geographic match conditions (continent, region, city), and introduces GRN interpolation variable support.

warning

Important: This release requires Akamai Property Manager template v1.11.0 or later. Please reach out to your Akamai team for help upgrading.

New Features -> Match Conditions​

Origin Timeout Match Condition​

A new response match condition that allows rules to match based on whether the origin connection has timed out. This is available in the onClientResponse and onOriginResponse event handlers where response match conditions are supported.

  • origin_timeout: Matches when the origin connection has timed out
  • !origin_timeout: Matches when the origin connection has not timed out
  • Accepts boolean values (true/false) or string equivalents ("true"/"false")

Use this condition to implement custom error responses, fallback behaviors, or specific logging when origin servers are unresponsive.

Example: Serve a custom error response when the origin times out:

{
  "onClientResponse": {
    "features": {
      "respondWith": {
        "rules": [
          {
            "matchAll": {
              "origin_timeout": true
            },
            "args": {
              "status": 503,
              "headers": {
                "Content-Type": ["text/html"],
                "Retry-After": ["30"]
              },
              "body": "<html><body><h1>Service Temporarily Unavailable</h1><p>Please try again later.</p></body></html>"
            }
          }
        ]
      }
    }
  }
}

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:

{
  "onClientResponse": {
    "features": {
      "respondWith": {
        "rules": [
          {
            "matchAll": {
              "status": [502, 503, 504]
            },
            "args": {
              "status": 503,
              "body": "Upstream error — please retry."
            }
          }
        ]
      }
    }
  }
}

Example: Match a class of status codes:

{
  "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.

info

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:

{
  "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:

{
  "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:

{
  "onClientResponse": {
    "features": {
      "setHeaders": {
        "X-Request-ID": "{{grn}}"
      }
    }
  }
}

Example: Include GRN in custom error page:

{
  "onClientResponse": {
    "features": {
      "respondWith": {
        "rules": [
          {
            "matchAll": {
              "status": ["5xx"]
            },
            "args": {
              "status": 503,
              "body": "<html><body><h1>Service Error</h1><p>Request ID: {{grn}}</p></body></html>"
            }
          }
        ]
      }
    }
  }
}

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:

{
  "onClientResponse": {
    "features": {
      "respondWith": {
        "rules": [
          {
            "matchAll": {
              "status": ["5xx"]
            },
            "args": {
              "status": 503,
              "headers": {
                "Content-Type": ["text/html"],
                "Cache-Control": ["no-store"]
              },
              "body": "<html><body><h1>Service Error</h1><p>We are working on it.</p></body></html>"
            }
          }
        ]
      }
    }
  }
}

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.

warning

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​

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.

// Before
{
  "features": {
    "http2": true,
    "http3": true
  }
}

// After — remove these fields
{
  "features": {}
}

Resources​

note

Questions or feedback? Please refer to the documentation or contact support.