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 #

• If Token-Based Authentication 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 Ignore URL Case #

• ec_url_allow
• ec_ref_allow
• ec_ref_deny

Caching #

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 #

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 #

• 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 Status Codes #

• Caching 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.

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 most 1xx - 5xx status codes. The following status codes are unsupported: 100 | 101 | 102 | 103 | 201 | 202 | 204 | 205 | 206 | 207 | 208 | 226 | 303 | 304 | 306

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 #

• Our servers use the cache key to check for a cached version of an asset.
• A core component of a cache key is a relative URL path that starts directly after the hostname. This relative URL path is derived from the request whose response is being cached. This feature allows you to customize the default cache key for a set of requests by modifying this value.
• 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 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 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 Max Age#

• 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 #

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 more.

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.
• 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.

Server-Timing Header #

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.

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 #

• 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 #

• 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.

Set Origin #

Response #

Allow Prefetching of Uncached Content #

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 #

• Source Path: Define a relative path that identifies the requests that will be rewritten. This relative path starts directly after the hostname.
  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.
  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.

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