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.
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 our CDN will honor your caching policy when determining whether requests should be cached.
Default Behavior: false
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 theSet 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 aCache-Control
header when the origin server does not set it. - Ensures that the
-
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 theSet Client Max Age
feature to the response.
- Overwrites the
-
If missing: If a
Cache-Control
header was not received from the origin server, then this option adds theCache-Control
header produced by theSet Client Max Age
feature. This option is useful for ensuring that all assets will be assigned aCache-Control
header. -
Remove: Excludes the
Cache-Control
header from the response. If aCache-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.
-
Query String Parameters: Include or exclude all query string parameters by seting the Query Parameters option to either
Include All
orExclude All
. Alternatively, include or exclude specific query string parameters through theInclude Only
orInclude 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.
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 Status Codes
Defines the set of status codes that can result in cached content.
Key information:
- 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.
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
andPUT
requests, purge is only supported forGET
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 theSet 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 anExpires
header when the origin server does not set it. - Ensures that the
-
Overwrite: Ensures that the following actions will take place:
- Overwrites the
Expires
header generated by the origin server. - Adds the
Expires
header produced by theSet Client Max Age
feature to the response.
- Overwrites the
-
If missing: If an
Expires
header was not received from the origin server, then this option adds theExpires
header produced by theSet Client Max Age
feature. This option is useful for ensuring that all assets will be assigned anExpires
header. -
Remove: Ensures that an
Expires
header is not included with the header response. If anExpires
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 common
2xx
-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.Enabling this feature will generate
Cache-Control:max-age
and Expires
headers from our edge servers and send them to the HTTP client. By default, these headers will 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.Key information:
- 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 anExpires
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 that overrides the one defined in Cache-Control
or Expires
headers generated from an origin server. This interval defines the amount of time that will pass before an edge server can check whether a cached asset matches the asset stored on the origin server.Key information:
- 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
orExpires
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 themax_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
andx-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
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
andx-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
andx-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 thebroadcast
request header by specifying+broadcast
. If the request does not contain thebroadcast
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 toott
, 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
andx-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 thebroadcast
response header by specifying+broadcast
. If the response does not contain thebroadcast
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 toott
, 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
andx-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 is192.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 is2001: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
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
andSet 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 requests may be redirected to the hostname defined in the
Location
header returned by an origin server.All requests, regardless of HTTP method (e.g.,
POST
and PUT
), are redirected as GET
requests.Default Behavior: By default, our edge servers will not follow the redirect defined in the
Location
response header returned by an origin server.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.