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

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 #

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 #

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