Access Control
|
Deny Policies
|
Allows you to reject a request or redirect it to another URL. This feature allows you to set the following aspects a request rejection response:
- denial action: redirect to another URL or present a standard non-customizable error.
- destination redirect URL: URL of the redirected response.
You can also add custom headers to your denial response.
Format: form-based, input required
Supported match block type: client request
|
Geo Restrictions
|
Restricts access based on request's origination country based on a referenced (definition) list of countries for a specified region.
You can use this feature in Allow (Whitelist) mode - declare only those geo regions that are allowed, causing all others to be blocked, or in Deny (Blacklist) mode - declare the blocked regions, which assumes all other are allowed. You can also create exceptions based on a clients IP address. The following parameters can be applied when invoking this feature.
- action type - allows or denies the requests originating from countries included in the referenced geo region list
- denial action - returns a non-customizable error or forwards to a URL when a request is denied
- destination redirect URL - URL to redirect to, to use when the denial action is set to redirect
- IP white list - allows a specified list of requests originating from a specified list of IP addresses to gain access even though they belong in a restricted region
- match anonymizers - when enabled, requests with anonymizing proxies will be denied regardless of the from which region they originate
Format: form-based, input and definitions required
Supported match block type: client request
|
IP Restrictions
|
Restricts access based on requests originating from any IP address specified in the referenced IP list. You can use this feature in Allow (Whitelist) mode - declare only IPs that are allowed access, causing all others to be block, or in Deny (Blacklist) mode - declare the IPs block, which assumes all other are allowed. The following parameters can be applied when invoking this feature:
- Allow / Deny mode - allows or denies the requests originating from countries included in the referenced IP list.
- denial action - returns a non-customizable error or forwards to a URL when a request is denied
Format: form-based, input and definitions required
Supported match block type: client request
|
Token Authentication
|
Defines token generation characteristics for a protected resource that is matched against a request with an embedded token. The following components support how to generate the token and how to handle the response if denied.
- denial action - returns a non-customizable error or forwards to a URL when a request is denied
- destination redirect URL - when the denial action is set to redirect
- IP white list - allows a specified list of requests originating from a specified list of IP addresses to gain access even though the token comparison failed
- shared secrets (up to 10) - characters that will become part of the hashed together token value
- hash - the characters that will indicate the middle of either side of the hashed outcome
- query parameter names - a list of parameter names in the query strings to include in the token comparison operation
- nva (not-valid-after) - the expiration date of the token authentication policy
- nvb (not-valid-before) - the date when the token authentication policy become valid
- date preference - indicates if the date representation for validity is represented in GMT or EPOCH
The token should be created by the content provider and embedded into the object URL as a set of query string parameters.
When the client presents the URL to the CDN, the CDN creates its own version of the token using a shared secret and pre-defined token generation algorithm (sha1). If the client’s token does not match, the CDN will return either an HTTP 403 response or 302 Temporary Redirect. If the client’s token matches the CDN calculated token, the client’s request is allowed to proceed and the requested object is returned to the client.
Note: this feature also requires an implementation on the client side in order to generate the token and add it to the request URL.
Format: form-based, input required, definitions required
Supported match block type: client request
|
Cache Control
|
Cache Control Header Override (CCHO)
|
The Cache Control Header Override (CCHO) feature allows for any origin provided cache control information to be over-ridden, if present, or applied, if absent, from origin responses to fill requests. The Cache Control Header Override feature can have both an internal and external policy. The internal Cache Control Header Override policy instructs the CDN as to how it should cache the object. The external policy instructs the CDN as to what information to include in the response sent to the client, influencing how the client caches the received content.
Both the internal and external policies can take either an integer value expressed in seconds (TTL - time-to-live). Alternatively, you can select other non-TTL-based options as shown below.
Internal Policies
- TTL: When the internal cache policy is set to a positive number, it is interpreted as if it were a max-age header when determining the internal cache lifetime. If value is 0, act as “no-cache”. If value is -1, acts as “no-store”. The minimal value allowed for the parameter is 30 seconds. If you need a lower value, please contact our Support team.
- no-cache : causes the resource is pre-expired at the CDN node. It will be cached, but the next request for it will trigger a revalidation to the origin.
- no-store: prevents the resource from being cached by the CDN.
- as-is: the resource assumes the cache-control policy is provided by the origin. Use this in case you want to override the External Cache policy without touching the Origin one.
External Policies
- TTL: Setting the external cache policy to a positive value, will result in a ‘Cache-Control: max-age’ and/or an ‘Expires:’ header being added to the resource, with the values set appropriately given the Date: at the time the resource is served from cache, and the value of ‘ext’. (The ‘Expires:’ header is currently being added to the resources served from cache based on the time of resource load and max-age).
- no-cache : if selected, then an explicit ‘no-cache’ policy is added when the resource is served from the cache - ie, both ‘Pragma: no-cache’ and ‘Cache-Control: no-cache’ headers are added.
- no-store: prevents the resource from being cached by the CDN client request, origin request, origin response
For external policies, the force option is offered. By default, the cache policy manipulation is NOT performed if the resource had a cache control policy when served from the origin server, unless the optional force attribute is activated. In that case, any existing cache headers are removed in favor of the external headers added due to the values of the external cache policy.
Format: form-based, input required
Supported match block type: client request, origin request, origin response
|
Default Cache Control Policy
|
Default Cache Control Policy provides an internal (CDN Edge node response) and external (client response) TTL-based (time-to-live) caching policy to be applied only in the case when not provided by the origin.
Supported match block type: client request, origin request, origin response
Format: form-based, input required
|
Failed Refresh TTL
|
Specifies the TTL (time-to-live) expressed in seconds for which an expired cached resource can be served upon failure of an attempted refresh on the origin.
This option can improve reliability on high loads. It can be used to prevent short traffic disruptions in case the CDN has momentarily problems fetching a resource from the origin due to network issues, and can also be used to reduce the load on the origin when it is already under high load and has troubles responding in time to the CDN.
Format: form-based, input required
Supported match block type: client request, origin request, origin response
|
Negative TTL
|
Defines the time-to-live (TTL) in seconds for the following origin response status codes: 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, 504.
Could be either a numeric value (Int) which defines the TTL in seconds, or a String with one of these values:
“no-cache”: The no-cache directive will cache the negative status code response, but the response must be validated with the origin before each reuse.
“no-store”: The no-store directive will not cache the negative status code response, and therefore each request will pass through the cache and be forwarded to the origin.
If using a numeric TTL, it must be greater than 0. 0 does NOT equate to “no-cache” and -1 does NOT equate to “no-store”. If you want to set a cache policy of “no-cache”, use the string “no-cache” and if you want to set a cache policy of “no-store”, use the string “no-store”.
Format: form-based, input and definitions required
Supported match block type: client request, origin request, origin response
|
Disable If-None-Match Header
|
If disabled (false) this feature instructs the CDN to NOT to use the If-None-Match header and Etag comparison when refreshing a resource. By default, this features is enabled and only needs to be added used if the inverse is desired.
Format: form-based, input required, definitions required
Supported match block type: client request
|
Query Strings Handling
|
Allows you to specify which query strings to include or ignore when determining the cache key.
Choose to include or exclude:
- All Query Strings
- Specified Query Strings: in that case, you can define the query strings you want to either exclude from cache key, or keep in cache key.
Note that by default, all query strings are ignored. If that is the intended behavior, you do not need to add this feature.
Format: form-based, input and definitions required
Supported match block type: client request
|
Stale Content Control
|
Permits serving stale content based on the conditions you specify. Multiple conditions are assumed as an “or” operator.
- If an error occurs
- If the resource is in the process of being refreshed
- if 4xx errors accompany the response
- if 5xx errors accompany the response
Format: form-based, input required
Supported match block type: client request, origin request, origin response
|
Cache Key Modification
|
Defines a new cache key for the request. The value is a string. The string is interpolated, which allows the new cache key to be set in terms of the original URI or other variables.
Note: The current URI Rewrite feature resets the cache key property, so if URI Rewrite runs after Cache Key, then the newly rewritten URI is used to form the cache key meaning the value set for the Cache Key feature will NOT be used. However, if Cache Key is processed after URI Rewrite or if URI Rewrite and Cache Key are within the same feature block then the value set for Cache Key is used for the cache key property.
Format: form-based, input required
Value type: string (interpolated)
Supported match block type: client request
|
Request Manipulation
|
Generated Responses
|
Allows you to create an auto-generated response template that is used instead of the one provided by the cached resource or the origin.
This feature allows you to set the following aspects of the generated response by creating a new, or reusing an existing Generated Response definition.
- status code (required): HTML status code of the response
- reason : response code associated with status code (example: OK for status code 200)
- mime type: mime type of the response
- headers: headers key-value pairs you would like to add to the response
- payload: body response. HTML code can be used here.
- description: an optional description of your response definition.
Format: form-based, definition required
Supported match block type: client request, origin request, origin response
|
Request Headers Manipulation
|
This feature allows you to override existing headers of a request. If used in a client request match rule, the changes are made before contacting the origin. If used for an origin request the header operations are done just before sending a request to the origin.
Format: form-based, definitions required
Format: form-based, input and definitions required
Supported match block type: client request, origin Request
|
Response Headers Manipulation
|
This feature allows you to add, remove, or modify headers in a response. If used in a client request or response match rule, the changes are made before sending a response to a client. If used in an origin request match rule, response header modifications are done just before saving a resource in CDN Edge cache.
Format: form-based, definitions required
Supported match block type: client request , origin request, origin response
|
Serve 200 for 416
|
When a client range request is out of range for the resource served, instead of returning a HTTP 416 error response, return the full resource.
Format: binary (enable/disable)
Supported match block type: client request, origin request, origin response
|
URI Rewrite
|
Using this feature allows you to define a replacement URI for a specified request.
Format: form-based, input required, definitions required
Supported match block type: client request, origin request
|
Follow Redirects
|
Defines behaviors related to redirects.
- Always: If the origin returns a 301,302,303 or 307 redirect with a location header, it will be followed instead of serving it to the client
- Never: Never serve received redirects to the client
Format: form-based
Supported match block type: origin request, origin response
|
Content Manipulation
|
Allow Compress
|
Allows the CDN to automatically Gzip your content and cache a compressed version of it on the CDN edges.
If your content is already Gzipped on your Origin, this option also allows the CDN to unzip your content on-the-fly and serve it unzipped if the client requests it.
This feature allows you to deliver your content faster and reduce the amount of data delivered. If your origin already supports both gzip an unzipped content, activating this feature can also help you reduce number of requests made to origin, by caching both versions of the content in the CDN Edge nodes.
Format: binary (enable/disable)
Supported match block type: client request, origin request, origin response
|
Origin Selection
|
Origin Fill Policy (use alternate)
|
Allows you to use an alternate origin fill policy definition that overrides the default one set up in the property.
You can either create a one or re-use a pre-existing one.
Format: definition required
Supported match block type: origin request
|
Logging
|
Custom Log Data
|
This feature allows you to create key-value pairs of static and/or variable information that will appear in the ‘x-extras' section of raw request logs of your traffic. Static key-value pairs simply add a label and static value such as: key=CDN, and value=Lumen. Alternatively, you can create a static key value that corresponds to a dynamic element expressed as a variable. Below you’ll find the supported variable options to select from:
- $prop.listener-addr -IP address of the server which accepted a request
- $prop.cli-ssl.proto - returns the TLS protocol of an established SSL connection
- $req.h.<name> - value of a client request header
- $resp.h.<name> - value of a client response header
- $resp.status - response HTTP status
You can add several key-value pairs.
Learn more about log streaming and log management
Format: form-based, input required
Supported match block type: client request, Origin Request
|
Reporting Overrides
|
Allows the requests corresponding to the Match Rule to be assigned a specific tag inside the property. This feature will allow you to see traffic and QoS data for the tagged resources separately from the whole property data (tagged under the primary alias).
The data under this new tag will not be counted as part of the primary alias anymore.
Format: definition required
Supported match block type: client request
|
Lua
|
Lua Scripts -
Request
|
Executes a specified lua script while processing a request. When applying this feature, if the lua script contains variables, their values must be provided. Only Lumen support engineers can create Lua scripts, however you decide the variable values and where to apply them.
Format: form-based (for variables), definitions required
Supported match block type: client request, origin Request
|
Lua Scripts - Response
|
Executes a specified lua script while processing a response. When applying this feature, if the lua script contains variables, their values must be provided. Only Lumen support engineers can create Lua scripts, however you decide the variable values and where to apply them.
Format: form-based (for variables), definitions required
Supported match block type: client request, origin request, origin response
|
