Edgio

Features Reference

A feature identifies an action that will be applied to a request. Features are categorized as follows:
  • 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

Access features control access to content.

Deny Access

Determines whether requests are rejected with a 403 Forbidden response.
Default Behavior: false

Token Auth

Determines whether Token-Based Authentication will be applied to a request.
  • 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.
You may not currently set a primary and backup encryption key through the Edgio Console. Contact our technical customer support to set these key(s).
Default Behavior: false

Token Auth Ignore URL Case

Determines whether URL comparisons made by the following Token-Based Authentication parameters are case-sensitive:
  • ec_url_allow
  • ec_ref_allow
  • ec_ref_deny
Default Behavior: false

Caching

Caching features customize when and how content is cached.

Bandwith Throttling

Throttles the bandwidth for the response provided by our edge servers.
This feature also allows bandwidth throttling to be customized on a per request basis through query string parameters (i.e., ec_rate and ec_prebuf).
  • 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.
Default Behavior: By default, our CDN does not throttle requests.

Bypass Cache

Determines whether the request may leverage our caching technology.
  • 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.
Default Behavior: Disabled.

Bypass Client Cache

Determines whether our CDN will instruct the client to bypass 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.
An alternative method for defining a client’s caching policy is to set the cache-control response header through the Set Response Headers feature.
Default Behavior: false

Cache Control Header Treatment

Controls the generation of Cache-Control headers by an edge server when the Set Client Max Age feature is active.
The recommended method for setting up this feature is to add both Set Client Max Age and Cache Control Header Treatment features within the same rule.
Valid values are:
  • 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.
Default Behavior: Overwrite

Cache Key

Customizes the cache key through query string parameters, request headers, cookies, and custom metadata.
Learn more about cache keys.
  • 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.
Default Behavior: The default cache key includes all query string parameters and excludes request headers, cookies, and feature variables.

Cache Key Query String

Determines whether the cache key will include or exclude query string parameters associated with a request.
Learn more about cache keys.
Include or exclude all query string parameters through the Include All or Exclude All modes. Alternatively, include or exclude specific query string parameters through the Include 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: 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.
Default Behavior: By default, Edgio includes all query string parameters when constructing the cache key.

Cacheable Request Body Size

Restricts caching to requests whose body does not exceed the specified file size.
Key information:
  • 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
Default Behavior: 14kB

Cacheable Status Codes

Defines the set of status codes that can result in cached content.
Key information:
  • 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.
Default Behavior: By default, caching is restricted to responses that generate a 200 OK status code.

Enable Caching for Methods

Determines whether POST and PUT requests are eligible for caching on our network.
Key information:
  • 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.
Default Behavior: By default, only GET requests are eligible for caching.

Expires Header Treatment

Determines how an edge server will handle the Expires response header when the Set Client Max Age feature is active. This feature overrides the Expires header generated by the Set Client Max Age feature.
The recommended method for setting up this feature is to add the Set Client Max Age along with this feature within the same rule.
Valid values are:
  • 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.
Default Behavior: Overwrite

Honor No Cache Request Header

Determines whether an HTTP client’s no-cache requests will be forwarded to the origin server. A no-cache request occurs when the HTTP client sends a Cache-Control:no-cache and/or Pragma:no-cache header in the HTTP request.
For all production traffic, it is highly recommended to leave this feature in its default disabled state. Otherwise, origin servers will not be shielded from users who may inadvertently trigger many no-cache requests when refreshing web pages, or from the many popular media players that are coded to send a no-cache header with every video request. Nevertheless, this feature can be useful to apply to certain non-production staging or testing directories, in order to allow fresh content to be pulled on-demand from the origin server.
The cache status that will be reported for a request that is allowed to be forwarded to an origin server due to this feature is TCP_Client_Refresh_Miss. Use this cache status to track the number and percentage of requests that are being forwarded to an origin server due to this feature.
Default Behavior: The default behavior is to prevent no-cache requests from being forwarded to the origin server.

Ignore Origin No Cache

Determines on a per HTTP status code basis whether our CDN will ignore cache directives served from an origin server.
  • 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.
Default Behavior: The default behavior is to honor the above directives.

Ignore Unsatisfiable Ranges

Determines the response that will be returned to clients when a request generates a 416 Requested Range Not Satisfiable status code. By default, this status code is returned when the specified byte-range request cannot be satisfied by an edge server and an If-Range request header field was not specified.
Enabling this feature prevents our edge servers from responding to an invalid byte-range request with a 416 Requested Range Not Satisfiable status code. Instead our servers will deliver the requested asset and return a 200 OK to the client.
Default Behavior: The default behavior is to honor the 416 Requested Range Not Satisfiable status code.

Partial Cache Sharing Min Hit Size

Defines the minimum file size (bytes) for caching partial content.
Default Behavior: By default, partial cache sharing is disabled.

Prevalidate Cached Content

Determines whether cached content will be eligible for early revalidation before its TTL expires. Define the amount of time prior to the expiration of the requested content’s TTL during which it will be eligible for early revalidation.
Default Behavior: Revalidation may only take place after the cached content’s TTL has expired.

Refresh Zero Byte Cache Files

Determines how an HTTP client’s request for a 0-byte cache asset is handled by our edge servers.
Enabling this feature causes our edge server to re-fetch the asset from the origin server.
This feature is not required for correct caching and content delivery, but may be useful as a workaround. For example, dynamic content generators on origin servers can inadvertently result in 0-byte responses being sent to the edge servers. These types of responses are typically cached by our edge servers. If you know that a 0-byte response is never a valid response for such content, then this feature can prevent these types of assets from being served to your clients.
Default Behavior: The default behavior is to serve valid cache assets upon request.

Revalidate After Origin Unavailable

Defines the length of time that Edgio will be allowed to serve an expired cached asset when an edge server is unable to revalidate that asset with the origin server.
Normally, when an asset’s max-age time expires, the edge server will send a revalidation request to the origin server. The origin server will then respond with either of the following status codes:
  • 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.
If the edge server is unable to establish a connection with the origin server while attempting such a revalidation, then this feature controls whether, and for how long, the edge server may continue to serve the now-stale asset.
This time interval starts when the asset’s max-age expires, not when the failed revalidation occurs. Therefore, the maximum period during which an asset can be served without successful revalidation is the amount of time specified by the combination of max-age plus max-stale.
For example, if an asset was cached at 9:00 with a max-age of 30 minutes and a max-stale of 15 minutes, then a failed revalidation attempt at 9:44 would result in a user receiving the stale cached asset, while a failed revalidation attempt at 9:46 would result in the user receiving a 504 Gateway Timeout.
Any value configured for this feature is superseded by Cache-Control:must-revalidate or Cache-Control:proxy-revalidate headers received from the origin server. If either of those headers is received from the origin server when an asset is initially cached, then the edge server will not serve a stale cached asset. In such a case, if the edge server is unable to revalidate with the origin when the asset’s max-age interval has expired, then the edge server will return a 504 Gateway Timeout.
Each stale response includes a Warning response header.
Default Behavior: 2 minutes

Revalidate While Stale Timer

Determines how often, in seconds, the system will attempt to connect to an unavailable origin server.
Key information:
  • 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.
Default Behavior: By default, our CDN will not attempt to connect to your origin server while it is in stale mode.

Rewrite Cache Key

Rewrites the default cache key for a set of requests.
Key information:
  • 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).
View examples on how to add cookies or the client’s country to the cache key.
Default Behavior: By default, Edgio uses the request URI’s relative path and query string, if present, when constructing the cache key.

Set Client Max Age

Determines the max-age interval for browser to edge server cache revalidation. In other words, the amount of time that will pass before a browser can check for a new version of an asset from an edge server.
Key information:
  • 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.
Default Behavior: The Cache-Control / Expires headers cached with the response from the origin server will pass through to the browser.

Set Max Age

Defines a max-age interval for edge server to origin server cache revalidation. In other words, the amount of time that will pass before an edge server will check whether a cached asset matches the asset stored on the origin server.
Key information:
  • 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

Set the amount of time that must pass before a browser can check for a new version of a prefetched request. Specifically, it determines the max-age interval for the Prefetch service worker to edge server cache revalidation.
Key information:
  • 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.
Default Behavior: By default, all prefetched requests are cached by service workers and our edge servers for 2 minutes.

Stale On Error

Determines whether expired cached content will be delivered when an error occurs during cache revalidation or when retrieving the requested content from an origin server.
Enabling this feature serves stale content when an error occurs during a connection to an origin server. Use the Revalidate After Origin Unavailable feature to configure the length of time after TTL expiration during which stale content may be delivered.
Each stale response includes a Warning response header.
Default Behavior: By default, we forward the origin server’s error response to the user.

Stale While Revalidate

Improves performance by allowing our edge servers to serve stale content while revalidation takes place.
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.
Default Behavior: Revalidation must take place before the requested content can be served.

Headers

Header features add, modify, or delete headers from the request or response.

Add Response Headers

Adds one or more header(s) to the response.
Key information:
  • 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.
Example:
If you configure this feature to add the event-type response header set to basketball, then it will set the following response header when the response does not already contain that header or if it is set to a blank value:
event-type: basketball
However, if the response already contains an event-type response header set to sports, then it would add another event-type header to the response.
event-type: sports event-type: basketball

Debug Header

Determines whether a response may include debug cache response headers. These response headers provide information on the cache policy for the requested asset.
Our CDN returns debug cache response headers when both of the following are true:
  • 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.
Default Behavior: By default, the response excludes debug cache response headers.

Remove Origin Response Headers

Deletes one or more custom header(s) from the response provided by an origin server.
Key information:
  • 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

Deletes one or more header(s) from a response.
Key information:
  • 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

Adds a custom request header that identifies the requesting client by IP address.
Define the name of the custom request header to which the requesting client’s IP address will be logged.
Key information:
  • 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

Set, overwrite, append, or delete one or more header(s) from the response provided by an origin server.
Key information:
  • 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

Set, overwrite, append, or delete one or more header(s) from the request.
Key information:
  • 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

Set, overwrite, append, or delete one or more header(s) from the response.
Key information:
  • 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

Log features customize how log data is stored.

Custom Log Field

Determines the value that will be assigned to RTLD’s custom log field.
Key information:
  • 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
Default Value: -

Log Query String

Determines whether a query string will be stored along with the URL in access logs. This feature does not apply to requests whose URL does not contain a query string.
Default Behavior: The default behavior is to ignore query strings when recording URLs in an access log.

Mask Client Subnet

Masks the client’s subnet for logging and reporting purposes.
This feature masks a client’s subnet by:
  • 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
Use this feature as part of your General Data Protection Regulation (GDPR) compliance strategy.
Default Behavior: By default, the system logs a client’s IP address without masking.

Origin

Origin features control how the CDN communicates with an origin server.

Max Keep-Alive Requests

Defines the maximum number of requests for a Keep-Alive connection before it is closed.
Key information:
  • 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.
Default Behavior: 10,000 requests

Proxy Special Headers

Defines the set of CDN-specific request headers that will be forwarded from an edge server to an origin server.
Key information:
  • 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.
Default Behavior: By default, CDN-specific request headers are forwarded to the origin server.

Set Origin

Defines the origin configuration to which requests will be forwarded when they cannot be served from cache.
Default Behavior: By default, requests that are not served from cache are served through either the Edgio cloud or the origin configuration mapped to the request’s hostname.

Response

Response features manipulate the response sent to the client.

Allow Prefetching of Uncached Content

Determines whether prefetching will be allowed for cache misses.
Default Behavior: By default, prefetching is disabled for cache misses.

Compress Content Types

Defines the set of media types (aka content type) that are eligible for edge server compression.
Key information:
  • 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

Determines whether Edgio will be allowed to process or generate an image for eligible requests.
This feature should only be enabled for images that will be transformed by Edgio. This is critical if you use the Accept-Encoding header to compress content, since Edgio removes this header from all requests that it processes.
Upon enabling this feature on the desired set of requests, Edgio will look for client hints and check the query string to determine the set of optimizations that will be applied to an image.

Set Done

Determines whether to prevent the request from being proxied from our network to an origin server.
Key information:
  • Combine this feature with the Set Status Code and Set Response Body features to optimize performance for custom responses.
Default Behavior: By default, cache misses are forwarded to an origin server.

Set Response Body

Defines a custom response body.
Key information:
  • 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.
Default Behavior: By default, our CDN does not alter the response body sent to the client.

Set Status Code

Defines the HTTP status code for the response sent to the client.
Default Behavior: By default, the HTTP status code indicates how the request was handled.

Set Variables

This feature assigns a value to one or more user-defined variable(s) that are passed to your bespoke traffic processing solution. Define each desired variable as a key-value pair.
Key information:
  • 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>"
Default Behavior: By default, our CDN does not pass user variables.

URL

URL features redirect or rewrite requests to a different URL.

Follow Redirects

Determines whether Edgio will follow a redirect defined within the Location header returned by an origin server.
Key information:
  • 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.
Default Behavior: By default, our edge servers will not follow the redirect defined in the Location response header returned by an origin server. This allows a client (e.g., a web browser) to determine whether to follow the redirect.

Rewrite URL

Rewrites the request URL.
This feature allows our edge servers to rewrite the URL without performing a traditional redirect. This means that the client will receive the same response code as if the rewritten URL had been requested.
This feature takes precedence when multiple features will be applied to a request.
  • 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)
Default Behavior: By default, requests are not rewritten.

URL Redirect

Redirects requests according to the Location header. Pass the following properties:
  • 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.
Default Behavior: By default, requests are not redirected.