Features Reference

• Access: Controls access to content.
• Caching: Customizes when and how content is cached.
• Client: Controls how the client communicates with our CDN.
• Comment: Adds a note or metadata to your configuration. This feature is solely informational and does not affect your configuration.
• Headers: Adds, modifies, or deletes headers from the request or response.
• Log: Customizes how log data is stored.
• Origin: Controls how the CDN communicates with an origin server.
• Response: Customizes the response sent to the client and determines whether we will allow prefetching instructions to be sent to the client.
• Set Variables: Assigns a value to one or more user-defined variable(s) that are passed to your bespoke traffic processing solution.
• URL: Redirects or rewrites requests to a different URL.

Access #

• Deny Access
• Token Auth
• Token Auth Denial Code
• Token Auth Ignore URL Case
• Token Auth Parameter

Deny Access #

Token Auth #

• If Token Auth is enabled, then only requests that provide an encrypted token and satisfy the requirements specified by that token will be honored.
• Token values will be encrypted and decrypted using your primary and backup encryption key(s).
• This feature takes precedence over most features with the exception of the Rewrite URL feature.

Token Auth Denial Code #

• Status code: Determines the HTTP status code for the response for requests denied due to Token Auth.
• Http Response Header: Contains one or more response header(s) that are specific to the status code set by the Status code option.
  • 3xx: Set the Location response header to the URL to which denied requests will be redirected. If this header is not set, then we will return a standard response page.
  • 401: Set the WWW-Authenticate response header to info on how to authenticate. If the WWW-Authenticate header is set to basic, then the unauthorized user will be prompted for account credentials.

Token Auth Ignore URL Case #

• ec_url_allow
• ec_ref_allow
• ec_ref_deny

Token Auth Parameter #

Caching #

• Add Early Hints
• Bandwith Throttling
• Bypass Cache
• Bypass Client Cache
• Cache Control Header Treatment
• Cache Key
• Cache Key Query String
• Cacheable Request Body Size
• Cacheable Status Codes
• Enable Caching for Methods
• Enable Early Hints
• Expires Header Treatment
• Honor No Cache Request Header
• Ignore Origin No Cache
• Ignore Unsatisfiable Ranges
• Partial Cache Sharing Min Hit Size
• Prevalidate Cached Content
• Refresh Zero Byte Cache Files
• Revalidate After Origin Unavailable
• Revalidate While Stale Timer
• Rewrite Cache Key
• Set Client Max Age
• Set Default Internal Max Age
• Set Max Age
• Set Service Worker Max Age
• Stale On Error
• Stale While Revalidate

Add Early Hints #

• Upon receiving a request for which this feature is applicable, Edgio will immediately respond with a 103 Early Hints response when the following conditions are met:
  • The requested content cannot be served immediately from cache.
  • Early hints have not been cached for the requested content.
    If early hints for the requested content were previously cached, then they will take precedence over those defined within this feature.
• Define each desired early hint by specifying a Link header value and then pressing ENTER. This value must contain a rel attribute set to either:
  • preload: Instructs the client to preemptively fetch and cache the asset.
  • preconnect: Instructs the client to preemptively establish a connection to the origin.
  Example: </style.css>; rel=preload; as=style
• This feature caches 103 Early Hints responses regardless of whether the response for the requested content is uncacheable.
• An origin server can also provide early hints through Link headers. Serve and cache an origin server’s early hints through the Enable Early Hints feature.

Bandwith Throttling #

• Kbytes per second: Set this option to the maximum bandwidth (Kb per second) that may be used to deliver the response.
• Prebuf seconds: Set this option to the number of seconds that our edge servers will wait until throttling bandwidth.
  The purpose of this time period of unrestricted bandwidth is to prevent a media player from experiencing stuttering or buffering issues due to bandwidth throttling.

Bypass Cache #

• Enabled: It forces all requests to fall through to the origin server even if the content was previously cached on edge servers.
• Disabled: Allows edge servers to cache content according to an origin’s cache instructions or a rule’s caching policy.

Bypass Client Cache #

• Bypass the cache: Sets the cache-control response header to: cache-control: private, no-cache, no-store, must-revalidate.
• Do not bypass the cache: No effect.

Cache Control Header Treatment #

• Pass: Ensures that the following actions will take place:
  • Ensures that the Cache-Control header produced by the Set Client Max Age feature is never added to the response.
  • If the origin server produces a Cache-Control header, it will pass through to the user.
  This mode may result in a response without a Cache-Control header when the origin server does not set it.
• Overwrite: Ensures that the following actions will take place:
  • Overwrites the Cache-Control header generated by the origin server.
  • Adds the Cache-Control header produced by the Set Client Max Age feature to the response.
• If missing: If a Cache-Control header was not received from the origin server, then this option adds the Cache-Control header produced by the Set Client Max Age feature. This option is useful for ensuring that all assets will be assigned a Cache-Control header.
• Remove: Excludes the Cache-Control header from the response. If a Cache-Control header has already been assigned, then it will be stripped from the response.

Cache Key #

• Query String Parameters: Include or exclude all query string parameters by seting the Query Parameters option to either Include All or Exclude All. Alternatively, include or exclude specific query string parameters through the Include Only or Include All Except modes.
  • Include All: Indicates that a unique cache key will be created for each request to an asset that includes a unique query string.
    This type of configuration is not typically recommended since it may lead to a small percentage of cache hits. This will increase the load on the origin server, since it will have to serve more requests.
  • Exclude All: Indicates that all query string parameters will be excluded from the cache key.
  • Include Only: Contains the set of parameter(s) that may be included in the cache key. A unique cache key will be generated for each request that contains a unique value for a query string parameter defined in this feature.
  • Include All Except: Contains the set of parameter(s) will be excluded from the cache key. All other query string parameters will be included in the cache key.
• Request Headers: Add a request header to the cache key by typing its name in the Headers option and then pressing ENTER. Repeat as needed. If the header is present in the request, then its value will be included within the cache key.
• Cookies: Add a cookie to the cache key by typing its name in the Cookies option and then pressing ENTER. Repeat as needed. If the cookie is present in the request, then its value will be included within the cache key.
• Custom Metadata: Include any combination of feature variables and static text through the Expressions option.
  The Expressions option supports autocompletion. Type %{ to see a list of feature variable suggestions.

Cache Key Query String #

• Include All: Indicates that a unique cache key will be created for each request to an asset that includes a unique query string.
  This type of configuration is not typically recommended since it may lead to a small percentage of cache hits. This will increase the load on the origin server, since it will have to serve more requests.
• Exclude All: Indicates that all query string parameters will be excluded from the cache key.
• Include: Contains the set of parameter(s) that may be included in the cache key. A unique cache key will be generated for each request that contains a unique value for a query string parameter defined in this feature.
• Include All Except: Contains the set of parameter(s) will be excluded from the cache key. All other query string parameters will be included in the cache key.

Cacheable Request Body Size #

• Syntax: <FILE SIZE>[B|kB|MB|GB|TB|kiB|MiB|GiB|TiB]
• Example: Both of the following sample values restrict caching to payloads that are 14 kilobytes or smaller:
  14000B or 14kB
• Units are case-sensitive.
• This feature is only applicable when POST or PUT responses are eligible for caching. Use the Enable Caching for Methods feature to enable POST / PUT request caching.
• Defining a large maximum request body size may impact data delivery performance.
  • Recommended Value: 14kB
  • Minimum Value: 1kB

Cacheable Status Codes #

• Caching a non-200 OK response also requires enabling the Ignore Origin No Cache feature.
• This feature cannot be used to disable caching for responses that generate a 200 OK status code.

Enable Caching for Methods #

• By default, our CDN restricts caching to requests whose body is smaller than 14 Kb.
  Use the Cacheable Request Body Size feature to set the maximum request body size for cache-eligible requests.
• Although you may enable caching for POST and PUT requests, purge is only supported for GET requests.

Enable Early Hints #

• Early hints provides the best performance improvement for low latency network requests that result in long server think times.
• This feature allows us to cache Link headers whose rel attribute is set to either:
  • preload: Instructs the client to preemptively fetch and cache the asset.
  • preconnect: Instructs the client to preemptively establish a connection to the origin.
• This feature will only cache and serve a 103 Early Hints response when the following conditions are met:
  • The Bypass Cache feature has not been applied to the request.
  • The requested content is not eligible to be cached on our network. Verify that a caching policy (e.g., Set Max Age) has not been applied to the request.
    If your origin server sets a caching policy through the Cache-Control header, then you should either:
    • Remove that header through the Remove Origin Response Headers feature.
    • Set the Cache-Control header to no-cache, no-store, or both cache directives through the Set Origin Response Headers feature.
• Add custom early hints through the Add Early Hints feature.

Expires Header Treatment #

• Pass: Ensures that the following actions will take place:
  • Ensures that the Expires header produced by the Set Client Max Age feature is never added to the response.
  • If the origin server produces an Expires header, it will pass through to the user.
  This mode may result in a response without an Expires header when the origin server does not set it.
• Overwrite: Ensures that the following actions will take place:
  • Overwrites the Expires header generated by the origin server.
  • Adds the Expires header produced by the Set Client Max Age feature to the response.
• If missing: If an Expires header was not received from the origin server, then this option adds the Expires header produced by the Set Client Max Age feature. This option is useful for ensuring that all assets will be assigned an Expires header.
• Remove: Ensures that an Expires header is not included with the header response. If an Expires header has already been assigned, then it will be stripped from the header response.

Honor No Cache Request Header #

Ignore Origin No Cache #

• This feature only affects these directives:
  • Cache-Control: private
  • Cache-Control: no-store
  • Cache-Control: no-cache
  • Pragma: no-cache
• This feature supports common2xx - 5xx status codes.

Ignore Unsatisfiable Ranges #

Partial Cache Sharing Min Hit Size #

Prevalidate Cached Content #

Refresh Zero Byte Cache Files #

Revalidate After Origin Unavailable #

• 304 Not Modified: This type of response gives the edge server a fresh lease on the cached asset.
• 200 OK: This type of response provides the edge server with an updated version of the cached asset.

Revalidate While Stale Timer #

• This feature determines how often the system will attempt revalidation with an origin server whose configuration is in stale mode due to repeated TCP connection failures. However, it does not apply to requests that have been assigned a Cache-Control: must-revalidate directive.

Rewrite Cache Key #

• This is an advanced feature that should only be used when you require precise control over the cache key. Consider using the Cache Key feature instead.
• Our servers use the cache key to check for a cached version of an asset.
• This feature allows you to customize the default cache key for a set of requests by replacing the following elements from the cache key:
  • Relative Path: This relative URL path, which starts directly after the hostname, is derived from the request whose response is being cached.
  • Query String: This query string is derived from the request whose response is being cached.
• This feature does not affect the cache key assigned to previously cached content.
• Define the following settings:
  • Source: Identify the set of requests that will use a different default cache key by setting this option to a relative URL path that starts directly after the hostname. This setting supports regular expression syntax.
    Verify that the specified relative path does not conflict with any conditions applied to this rule.
  • Destination: Define a replacement pattern that sets a new default cache key.
    Use feature variables to dynamically construct this relative path. However, you may not use response metadata when defining a cache key.
    You may use up to 9 numbered backreferences for text captured within the source property.

    For example, if the Source option contains two capture groups (e.g., /(sales|marketing)/(.*), then you may backreference them within the Destination option (e.g., /$1/$2).

Set Client Max Age #

• This feature adds Cache-Control:max-age and Expires headers to the response. By default, these headers overwrite those created by the origin server. However, the Cache Control Header Treatment and the Expires Header Treatment features may be used to alter this behavior.
• This action does not affect edge server to origin server cache revalidations. These types of revalidations are determined by the Cache-Control / Expires headers received from the origin server, and can be customized with the Set Max Age feature.
• Setting this feature to a negative value causes our edge servers to send a Cache-Control:no-cache and an Expires time that is set in the past with each response to the browser. Although an HTTP client will not cache the response, this setting will not affect our edge servers’ ability to cache the response from the origin server.

Set Default Internal Max Age #

• This default caching policy is only applied to responses from an origin server that have not been assigned a max-age directive through either the Cache-Control or Expires header.
• This default caching policy is inapplicable to requests that are not deemed cacheable.
• The Set Max Age feature overrides this default caching policy.
• This default caching policy does not affect browser to edge server cache revalidations.
  • Browser to edge server revalidation is determined by the Cache-Control or Expires headers sent to the browser, which can be customized through the Set Client Max Age feature.
• The results of this default caching policy do not have an observable effect on the response headers and the content returned from edge servers for your content, but it may have an effect on the amount of revalidation traffic sent from edge servers to your origin server.
• Configure this feature by performing the following steps:
  • Select the status code for which this default caching policy will be applied.
  • Specify an integer value and then selecting the desired time unit (i.e., seconds, minutes, hours, etc.). This value defines the default max-age interval.

Set Max Age#

• This feature overrides the max-age interval defined in Cache-Control or Expires headers generated from an origin server. However, it will not override private, no-store, or no-cache directives when present in the origin server’s response. Override these cache directives by enabling the Ignore Origin No Cache feature.
• Define a max-age interval for each desired HTTP status code. This caching policy will only be applied when the status code for the cached response matches the specified HTTP status code.
• This feature does not affect browser to edge server cache revalidations. These types of revalidations are determined by the Cache-Control or Expires headers sent to the browser.
• This feature does not have an observable effect on the response sent to a user. However, it may have an effect on the amount of revalidation traffic sent from our edge servers to the origin server.

Set Service Worker Max Age #

• This configuration does not affect edge server to origin server cache revalidations. These types of revalidations are determined by the Cache-Control / Expires headers received from the origin server, and can be customized with the max_age features.

Stale On Error #

Stale While Revalidate #

• Configure this feature by specifying an integer value and then selecting the desired time unit (i.e., seconds, minutes, hours, etc.). This value defines the length of time past TTL expiration during which stale content may be delivered.
  The following formula indicates the length of time during which stale content may be delivered:
  <TTL> + <STALE WHILE REVALIDATE TIME>
• Each stale response includes a Warning response header.
• Edgio revalidates requests when the origin returns a Cache-Control: s-maxage directive. This behavior occurs regardless of whether this feature has been applied to the request.

Headers #

• Add Response Headers
• Debug Header
• Remove Origin Response Headers
• Remove Response Headers
• Set Client IP Custom Header
• Set Origin Response Headers
• Set Request Headers
• Set Response Headers

Add Response Headers #

• Specify a header name that is an exact match for the desired response header. However, case is not taken into account for the purpose of identifying a header.
• Use alphanumeric characters, dashes, or underscores when specifying a header name.
• Use feature variables to dynamically construct header values.
• This feature requires Edgio to add a response header, regardless of whether that header already exists in the response. This may cause the response to include multiple headers with the same name.
  Use the Set Response Headers feature if you prefer to overwrite or append to a header when it already exists in the response.
• The following headers are reserved and cannot be modified by this feature:
  • accept-ranges
  • age
  • connection
  • content-encoding
  • content-length
  • content-range
  • date
  • server
  • trailer
  • transfer-encoding
  • upgrade
  • vary
  • via
  • warning
  • All header names that start with x-edg and x-ec are reserved.

Debug Header #

• This feature has been enabled on the desired request.
• The request includes the X-EC-Debug request header. This request header defines the set of debug cache response headers that will be included in the response.
• The syntax for the X-EC-Debug request header is:
  X-EC-Debug: <DEBUG CACHE HEADER 1>[,<DEBUG CACHE HEADER 2>,<DEBUG CACHE HEADER N>]
  Sample Request Header:
  X-EC-Debug: x-ec-cache,x-ec-check-cacheable,x-ec-cache-key,x-ec-cache-state
  Learn how to request debug cache information.

Remove Origin Response Headers #

• Set each string value to the exact name of the header that will be removed from the response provided by an origin server. Case is not taken into account for the purpose of identifying a header.
• Use alphanumeric characters, dashes, or underscores when specifying a header name.
• This feature only removes custom response headers (e.g., Partner-ID). You may not remove standard headers (e.g., Cache-Control and Date) from the origin’s response.
• Our service adds a set of reserved headers to each response. Although this feature removes a header from the response provided by the origin server, it does not affect whether our service will add a reserved header to the response.

Remove Response Headers #

• Set each string value to the exact name of the header that will be removed from the response. Case is not taken into account for the purpose of identifying a header.
  • Use alphanumeric characters, dashes, or underscores when specifying a header name.
  • The following headers are reserved and should not be removed by this feature:
    • accept-ranges
    • age
    • connection
    • content-encoding
    • content-length
    • content-range
    • date
    • server
    • trailer
    • transfer-encoding
    • upgrade
    • vary
    • via
    • warning
    • All header names that start with x-edg and x-ec are reserved.

Set Client IP Custom Header #

• Edgio includes this custom request header when proxying requests to your web servers.
• The following headers are reserved and cannot be modified by this feature:
  • accept-ranges
  • age
  • connection
  • content-encoding
  • content-length
  • content-range
  • date
  • server
  • trailer
  • transfer-encoding
  • upgrade
  • vary
  • via
  • warning
  • All header names that start with x-edg and x-ec are reserved.
• Your origin may restrict the use of certain request headers when transferring a client’s IP address.
  For example, Salesforce B2C Commerce prohibits the use of various request headers, including true-client-ip, when transferring a client’s IP address.

Set Origin Response Headers #

• Specify a header name that is an exact match for the desired response header. However, case is not taken into account for the purpose of identifying a header.
• Use alphanumeric characters, dashes, or underscores when specifying a header name.
• Use the following syntax to determine the action that will be applied to the response header:
  • Set: Set or overwrite a header’s value by specifying a header name that does not start with a + symbol.
  • Append: Add to the end of an existing response header value by prepending a + symbol to the header name.
    Example: Append a value to the broadcast response header by specifying +broadcast. If the response does not contain the broadcast header, then it will be set to the value defined in this feature (e.g., network). On the other hand, if it is already set to ott, then it will append the value defined in this feature (e.g., broadast: ottnetwork).
  • Delete: Set the header value to a blank value. Deleting a header will prevent it from being forwarded to an origin server by our edge servers.
• Use feature variables to dynamically construct header values.
• The following headers are reserved and cannot be modified by this feature:
  • forwarded-for
  • host
  • vary
  • via
  • warning
  • x-forwarded-for
  • All header names that start with x-edg and x-ec are reserved.

Set Request Headers #

• Specify a header name that is an exact match for the desired request header. However, case is not taken into account for the purpose of identifying a header.
• Use alphanumeric characters, dashes, or underscores when specifying a header name.
• Use the following syntax to determine the action that will be applied to the request header:
  • Set: Set or overwrite a header’s value by specifying a header name that does not start with a + symbol.
  • Append: Add to the end of an existing request header value by prepending a + symbol to the header name.
    Example: Append a value to the broadcast request header by specifying +broadcast. If the request does not contain the broadcast header, then it will be set to the value defined in this feature (e.g., network). On the other hand, if it is already set to ott, then it will append the value defined in this feature (e.g., broadast: ottnetwork).
  • Delete: Set the header value to a blank value. Deleting a header will prevent it from being forwarded to an origin server by our edge servers.
• Use feature variables to dynamically construct header values.
• The following headers are reserved and cannot be modified by this feature:
  • forwarded-for
  • host
  • vary
  • via
  • warning
  • x-forwarded-for
  • All header names that start with x-edg and x-ec are reserved.

Set Response Headers #

• Specify a header name that is an exact match for the desired response header. However, case is not taken into account for the purpose of identifying a header.
• Use alphanumeric characters, dashes, or underscores when specifying a header name.
• Use the following syntax to determine the action that will be applied to the response header:
  • Set: Set or overwrite a header’s value by specifying a header name that does not start with a + symbol.
  • Append: Add to the end of an existing response header value by prepending a + symbol to the header name.
    Example: Append a value to the broadcast response header by specifying +broadcast. If the response does not contain the broadcast header, then it will be set to the value defined in this feature (e.g., network). On the other hand, if it is already set to ott, then it will append the value defined in this feature (e.g., broadast: ottnetwork).
  • Delete: Set it to a blank value. Deleting a header will prevent it from being included in the response to the client.
  Use the Add Response Headers feature if you prefer to always add a header when it already exists in the response.
• Use feature variables to dynamically construct header values.
• The following headers are reserved and cannot be modified by this feature:
  • accept-ranges
  • age
  • connection
  • content-encoding
  • content-length
  • content-range
  • date
  • server
  • trailer
  • transfer-encoding
  • upgrade
  • vary
  • via
  • warning
  • All header names that start with x-edg and x-ec are reserved.

Log #

• Custom Log Field
• Log Query String
• Mask Client Subnet

Custom Log Field #

• A custom log field can contain any combination of header fields and plain text.
• Valid characters for this field include the following: alphanumeric (i.e., 0-9, a-z, and A-Z), dashes, colons, semi-colons, apostrophes, commas, periods, underscores, equal signs, parentheses, brackets, and spaces. The percentage symbol and curly braces are only allowed when used to specify a header field.
• The spelling for each specified header field must match the desired request/response header name.
• When specifying multiple headers, it is recommended to use a separator to identify each header.
  For example, an abbreviation may be used to identify each header.
  Sample Syntax: AE: %{Accept-Encoding}i A: %{Authorization}i CT: %{Content-Type}o
• This feature defines the value that will be set for the custom log field. If this feature is applied multiple times to the same request, then the last instance applied to the request will overwrite all previous instances.
• One use for this feature is to add request and response header values to your log data.
  • Request Header Syntax: %{<REQUEST HEADER>}i
    Examples: %{Accept-Encoding}i %{Referer}i %{Authorization}i
  • Response Header: %{<RESPONSE HEADER>}o
    Examples: %{Age}o %{Content-Type}o %{Cookie}o

Log Query String #

Mask Client Subnet #

• IPv4: Setting the last octet to 0.
  Sample Scenario:
  Applying this feature to a client whose IP address is 192.0.2.50 would result in the following masked IP address: 192.0.2.0
• IPv6: Setting the last 32 bits to 0.
  Sample Scenario:
  Applying this feature to a client whose IP address is 2001:DB8::DD22:42:1234 would result in the following masked IP address: 2001:DB8::DD22:42:0

Origin #

• Max Keep-Alive Requests
• Proxy Special Headers
• Set Origin

Max Keep-Alive Requests #

• Specify this value as a whole integer. Do not include commas or periods in the specified value.
• Setting the maximum number of requests to a low value is strongly discouraged and may result in performance degradation.

Proxy Special Headers #

• Assign a value by typing it and then pressing ENTER. Repeat this step as needed.
• Each CDN-specific request header defined in this feature will be forwarded to an origin server.
• Prevent a CDN-specific request header from being forwarded to an origin server by removing it from this list.

Set Origin #

Response #

• Allow Prefetching of Uncached Content
• Compress Content Types
• Optimize Images
• Set Done
• Set Response Body
• Set Status Code

Allow Prefetching of Uncached Content #

Compress Content Types #

• This feature only applies to assets whose size is less than 3 MB. Larger assets will not be compressed by our servers.
• Certain types of content, such as images, video, and audio media assets (e.g., JPG, MP3, MP4, etc.), are already compressed. Additional compression on these types of assets will not significantly diminish file size. Therefore, the compression of these types of assets is not recommended.
• Wildcard characters, such as asterisks, are not supported.

Optimize Images #

Set Done #

• Combine this feature with the Set Status Code and Set Response Body features to optimize performance for custom responses.

Set Response Body #

• Use feature variables to dynamically construct this response body.
• This response body is always sent instead of a cached response or the response provided by an origin server.
• Prevent requests from being forwarded to an origin server by also passing the Set Done feature.

Set Status Code #

Set Variables #

• This feature is only applicable when:
  • Custom logic that is specific to your traffic controls how requests will be processed. Our CDN service supports the capability to define customized traffic processing logic. This solution addresses specialized customer needs that cannot be implemented through standard configuration. If your CDN traffic requires a bespoke solution, then contact our Solutions Engineering team.
  • This bespoke solution expects a variable.
  Upon implementing a bespoke solution, a member of our Solutions Engineering team will provide information about a variable’s purpose and the information that should be passed to it.
  Variables defined by this feature will be ignored when either a bespoke solution has not been defined for your CDN account or the specified variable has not been defined within your solution.
• Feature variables may not be used when defining a user-defined variable.
• Valid characters for the variable name are: alphanumeric, dashes, underscores, and periods.
• Syntax: "<VARIABLE>": "<VALUE>"

URL #

• Follow Redirects
• Rewrite URL
• URL Redirect

Follow Redirects #

• All requests, regardless of HTTP method (e.g., POST and PUT), are redirected as GET requests.
• Edgio will only follow redirects to a registered hostname. Edgio returns a 404 Not Found response for hostnames whose traffic cannot be served by Edgio.

Rewrite URL #

• Source Path: Define a relative path that identifies the requests that will be rewritten. This relative path starts directly after the hostname.
  Key information:
  • Verify that the specified pattern does not conflict with this route’s path.
  • Use the Match Style option to determine whether this option is a relative path that supports named parameters (e.g., :productId) or a regular expression.
• Destination Path: Define a replacement pattern that sets a new relative path. This relative path starts directly after the hostname.
  Key information:
  • You may use up to 9 numbered backreferences for text captured within the source property.
    For example, if the Source Path option contains two capture groups (e.g., /(sales|marketing)/(.*), then you may backreference them within the Destination Path option (e.g., /$1/$2).
  • Use feature variables to dynamically construct the above paths. However, you may not use response metadata.
  • This feature is currently incompatible with the Extension (extension) match condition. However, you may define a regular expression pattern for the desired file extensions within the Source Path option.
    Example: /marketing/(.*)\.(jpg|jpeg|png)

URL Redirect #

• Status Code: Determines the HTTP status code for the response.
• Source: Define a regular expression that identifies the requests that will be redirected by their relative path. This relative path starts directly after the hostname.
  Verify that the specified pattern does not conflict with this route’s path.
• Destination: Define a replacement pattern for the URL to which the requests identified in the Source option will be redirected.
  Key information:
  • Use feature variables to dynamically construct the above paths. However, you may not use response metadata.
  • Redirecting requests to a relative path may result in an invalid URL when fielding requests from various hostnames. Use an absolute URL to ensure that requests are properly redirected.