• Query String Handling: Query strings are the set of key/value pairs that occur after the ? in a URL. The Query String Handling setting enables you to control how requests that contain query strings are handled by the CDN. The options for this setting are:

  • 0 - use qstring in cache key, and pass up: With this setting, the query string is saved as part of the URL cache key on the cache and will be used to identify content. Therefore, two URLs that are the same except for the query string will be saved as separate URL cache keys. In addition, the query string is passed up to either the Mid cache or Origin Server. This option is good to use when the content that is returned by the Origin Server depends on the query string. This is the default setting.

  • 1 - ignore in cache key, and pass up: With this setting, the query string is not saved as part of the URL cache key. Therefore, two URLs that are the same except for the query string will match the same URL cache key. In addition, the query string is passed up to either the Mid cache or Origin Server. This option is good to use when the content that is returned does not depend on the query string, but the Origin Server still requires the query string for other purposes, such as authentication or logging.

  • 2 - drop at edge: With this setting, the query string is not saved as part of the URL cache key. Therefore, two URLs that are the same except for the query string will match the same URL cache key. With this setting, the query string is not passed up to either the Mid cache or Origin Server.

• Regex Remap Expression: This setting enables you to configure a regular expression remap rule that modifies the URL that the client is requesting. The base remap rule modifies the original client request for retrieving content from the origin listed in the Base Origin Server URL field. Placing a rule in this field can override and replace the request URL. If the regular expression does not match the request URL, the Base Origin Server URL is used.

  Note	This feature cannot be used when the Query String Handling setting is set to “2 - drop at edge”.

  The following is the syntax for this field:

  regex_expression_fromURLpath remap_toURL options

  • regex_expression_fromURLpath: A regular expression that is evaluated to determine which client requests to remap. Any client requests that match this regular expression are remapped. By default, the regular expression only matches against the URL path and query string. The path will always start with a “/”.

  • remap_toURL: The URL to which you want to remap the matching client requests. Various substitution strings are allowed in the remap_toURL parameter during evaluation. For a list of substitution strings that can be used in this parameter, please refer to the open source documentation at https://docs.trafficserver.apache.org/en/5.3.x/reference/plugins/regex_remap.en.html.

  • options: Additional options that you want to apply to the remap rule. For a list of available options, please refer to the open source documentation at https://docs.trafficserver.apache.org/en/5.3.x/reference/plugins/regex_remap.en.html.

  For example:

  ^/(vod.*)/more http://www.vod.example/$h/$0/$1 

  Note

  By default, only the path and query string of the URL are provided for the regular expressions to match. The Regex Remap Settings tab of the Delivery Service profile enables you to specify parameters and settings that you can use to modify the behavior of what regular expressions will match. For more information on how to configure the Regex Remap parameters, see Regex Remap Settings.

• Geo Limit: The Geo Limit setting enables you to configure the Traffic Router to block client requests based on the coverage zone file (CZF) and the geolocation of the client IP address, depending on the option that you choose. The options for this setting are:

  • None: When Geo Limit is set to None, geo blocking is not enabled and the Traffic Router will check the Anonymous Blocking configuration to determine whether to allow the request. If Anonymous Blocking is not enabled, then ASN blocking is checked to determine whether to allow the request. If ASN Blocking is not enabled, the Traffic Router will allow all client requests. None is the default setting for Geo Limit.

    For more information on Anonymous Blocking, see Anonymous Blocking. For more information on ASN Blocking, see ASN Blocking.

  • CZF only: With this setting the Traffic Router will only allow requests from clients whose IP addresses match an entry in the CZF file. If the client IP address does not match an entry in the CZF file, then the Traffic Router will reject the client request.

    Note	The CZF file is discussed in more detail in the "Manage Client Routing" chapter. Also an example of the CZF file can be found in the "Example CZF File" appendix.

  • CZF + CountryCode(s): With this setting the Traffic Router will take the following steps:

    Note

    If you are setting Geo Limit to "CZF + CountryCode(s)", confirm that the MaxMind geolocation database has been configured in the Media Streamer deployment. For more information on configuring Media Streamer to use the MaxMind database, refer to the "Configure the MaxMind Database for Geolocation" appendix in the Cisco Media Streamer and Cisco Media Broadcaster Installation and Upgrade Guide.

    1. First the Traffic Router checks the CZF file. If the client IP address matches an entry in the CZF file, the Traffic Router will then check the client request against the Anonymous Blocking configuration to determine whether the request is allowed.

    2. If the client IP address does not match an entry in the CZF file, then the Traffic Router looks up the client IP address in a geolocation database to determine which country the client IP address is in. If the client IP address is in one of the countries listed in the Geo Limit Country Codes field, the Traffic Router will then check the client request against the Anonymous Blocking configuration to determine whether the request is allowed.

    3. If the client IP address is not in the CZF file and the client IP address is not in one of the countries listed in the Geo Limit Country Codes field, the Traffic Router checks the NGB whitelist if configured. If the client IP address matches an entry in the NGB whitelist, Anonymous Blocking is checked next to determine whether the request is allowed. If there is no NGB whitelist configured or if the client IP address does not match an entry in the NGB whitelist, the Traffic Router will reject the client request.

• Geo Limit Country Codes: Choose the country codes for the countries you want to permit client requests from. This field is used when Geo Limit is set to CZF + CountryCode(s).

• Geo Limit Redirect URL: If the Geo Limit field is set to either "CZF only"or "CZF + CountryCode(s)", you can enter a URL in this field that the Traffic Router will redirect the client to if their request is blocked. If you leave this field blank, the client will receive a “503 Service Unavailable” response.

  Note	You will only see this field if the Geo Limit is set to either "CZF only"or "CZF + CountryCode(s)".

• Bypass FQDN: The Bypass FQDN is used in the following situations:

  • Thresholds exceeded: If either the “Maximum Bits per Second Allowed Globally” or the “Maximum Transaction Allowed Globally” limits are reached, the Traffic Router will send any overflow traffic to the FQDN listed in the Bypass FQDN field. To redirect the requests to the Origin Server, you would enter the FQDN of the Origin Server. By configuring Bypass FQDN, the Maximum Bits per Second Allowed Globally, and the Maximum Transaction Allowed Globally settings, you can essentially place a quota on how much traffic and how many computing resources the Delivery Service can use.

    Note	You do not have to configure both the Maximum Bits per Second Allowed Globally and the Maximum Transaction Allowed Globally settings. However, you need to configure at least one of them for the Bypass FQDN setting to have any affect.

  • No caches available: If there are no caches available when the Traffic Router tries to route the client request, the Traffic Router will redirect the client request to the FQDN listed in the Bypass FQDN field. To redirect the requests to the Origin Server, you would enter the FQDN of the Origin Server. This essentially works like a “Last Resort Routing”.

• Maximum Bits per Second Allowed Globally: This setting is used in conjunction with the Bypass FQDN setting. The value that you enter in this field determines the maximum bits per second (bps) this Delivery Service can serve across all Edge caches. When this limit is reached, the Traffic Router diverts the overflow traffic to the Bypass FQDN destination.

  Note	For this setting to have any effect, you must also configure the Bypass FQDN setting.

• Maximum Transaction Allowed Globally: This setting is used in conjunction with the Bypass FQDN setting. The value that you enter in this field determines the maximum transactions per second that this Delivery Service can serve across all Edge caches. When this limit is reached, the Traffic Router diverts the overflow traffic to the Bypass FQDN destination.

  Note	For this setting to have any effect, you must also configure the Bypass FQDN setting.

• Traffic Router Log Request Headers: This field enables you to specify headers that you would like to include in the Traffic Router access log entries. To specify which headers to include, enter a list of header keys separated by __RETURN__ . For example, "Header1-Name __RETURN__ Header2-Name". You can add additional headers by separating them with "__RETURN__". These headers will appear after the "rh=" token. If the listed header name is not present, it will not be logged.

• Initial Dispersion: The Initial Dispersion setting determines how many copies of requested content are stored in the cache group. By default, the Initial Dispersion setting is 1, which means that only a single copy of the requested content is cached in the cache group. Therefore, by default only one cache server will have a copy of the content. If the cache server that contains the content goes offline or is overloaded, the content is moved to another cache server in the cache group. This optimizes the amount of storage that is available for caching content.

  However, if you have a piece of content that you know is going to be very popular, you may want OMD to cache more than one copy of the content. These copies would be created at the time of the initial request and the system would not have to wait for load or cache health settings to be reached before additional copies of the content are created. This would result in faster performance for the clients and better control of the bandwidth utilization. However, keeping multiple copies of the same content will reduce the amount of storage available for caching unique content.

  To configure OMD to cache more than one copy of the content that is served by the Delivery Service, from the Initial Dispersion drop-down list choose the number of copies of the content that you want to cache. These copies would be stored on different cache servers in the cache group. For example, if you choose 3, a copy of the content is stored on 3 different cache servers.

• IPv6 Routing Enabled?: This setting determines whether the Traffic Router will respond to IPv6 DNS (AAAA record) requests for the hostnames of the Delivery Service. The default setting is No, which means the Traffic Router will only respond to IPv4 DNS (A record) requests for the hostnames of the Delivery Service. If you change this setting to Yes, the Traffic Router will respond to both IPv6 DNS (AAAA record) requests and IPv4 DNS (A record) requests for the hostnames of the Delivery Service.

• Anonymous Blocking Enabled?: This setting determines whether this Delivery Service will use the Anonymous Blocking feature to determine whether a client request is allowed. If this value is set to Yes, the Anonymous Blocking profile settings that are configured for the Traffic Router that services this Delivery Service will be used to help determine whether a client request is allowed. For information on how Anonymous Blocking works and how it interacts with the other client blocking methods, see Understanding CDN Client Blocking Options. For information on how to configure the Anonymous Blocking settings of the Traffic Router profile, see Configure Anonymous Blocking.

  Note	You cannot enable Anonymous Blocking for DNS Delivery Services.

• Range Request Handling: Some of the content that the CDN may deliver can be very large, however the client may only need a portion of that file because they are only watching a portion of the content.

  To enable a client to request only a portion of a file, browsers and video players support a Range Request header, which denotes what part (bytes) of the content the client is requesting. For example, a client could make a request that they only want bytes 0 through 199 of the content (the first 200 bytes) or they may request that they want bytes from a range later in the file such as bytes 10,000 and 11,000. The Range Request Handling setting determines how the cache server handles the content from these requests. The options for this setting are:

  • 0- Don’t Cache: When you choose this option, the cache servers will not cache the content for any requests that contain a range request (essentially any partial object request). The cache servers pass through the request in order to delivery the content to the client, but they do not cache the content that they receive from the Mid cache group or Origin Servers. This is the default setting.

  • 1 - Use background_fetch plugin: When you choose this option, if a client makes a range request, for example they request only bytes 200-300 of an object, the cache server will cache the entire object but will return to the client only the requested range. The cache server delivers the range to the client as soon as the range is downloaded; it does not have to wait for the entire object to be cached before it can deliver the requested range to the client. However, the cache server will save the entire object in cache, in the background, in case another client wants either a portion of this object or the whole object.

  • 2 - Use cache_range_requests plugin: When you choose this option, the cache server will store requests for the same object but different byte ranges as separate unique objects in cache. For example, if a client asks for a byte range of 0-10 of a certain object, the cache server will cache those bytes as one object. If another client asks for a different byte range for the same object, for example bytes 5-10, the cache server will store this request as a completely separate unique object in cache, even though the byte range overlaps with a previous request.

    Note

    If you have clients that make range requests and you can control these requests so that they are aligned (the clients are requesting the same ranges for the same object), choosing option “2 - Use cache_range_requests plugin” would be beneficial. However, if you have many clients that make range requests but those range requests are not aligned, option 2 is not efficient because having a large number of range requests that are not aligned can result in a large number of objects with overlapping content stored in cache

• Delivery Service DNS TTL: This setting determines the TTL, in seconds, that the Traffic Router will set on the A record responses to the clients for the hostnames of this Delivery Service. When the IPv6 Routing Enabled setting is set to Yes, this TTL also applies to the AAAA record responses. The default is 3600 seconds.

• Geo Miss Default Latitude and Geo Miss Default Longitude: What these settings determine, depends on the value of the Geo Limit setting:

  • If the Geo Limit field is set to None: When Geo Limit is set to None, the Traffic Router will allow all client requests through and will use the CZF file to determine which cache group to direct the client to. If the check of the CZF file does not return a Cache to use for the request, Proximity routing is checked next, if it is enabled in the profile of the Traffic Router. (See Proximity Routing.)

    If Proximity routing is not enabled, or if Proximity routing does not return a Cache to use for the request, the Traffic Router will use geolocation based routing to determine a cache group the client request should use and then chooses a cache from that group. If no geolocation is available for the requesting address, the Geo Miss Default Latitude and Geo Miss Default Longitude settings of the Delivery Service are used to determine the closest cache group to use for the client request and then chooses a cache from that cache group. (See Geolocation Based Routing.)

  • If the Geo Limit field is set to CZF Only: When the Geo Limit is set to CZF file Only, the Geo Miss Default Latitude and Geo Miss Default Longitude settings are not used. This is because with this setting, only clients whose IP addresses match an entry in the CZF file are allowed through. If the client matches an entry in the CZF file, that entry will determine which cache group the client is directed to.

  • If the Geo Limit field is set to CZF + CountryCode(s): When Geo Limit is set to CZF file + CountryCode(s), if the client IP address does not match an entry in the CZF file, then the Traffic Router tries to determine the location of the client IP address using a geolocation database. If the Traffic Router cannot find the location of the client using the geolocation database, it will then use the Geo Miss Default Latitude and Geo Miss Default Longitude fields to determine what country the request is from.

    If the country location of the client matches a country listed in the Geo Limit Country Codes field, the Traffic Router will then check the client request against the Anonymous Blocking configuration to determine whether the request is allowed. If the client request is allowed, the Traffic Router uses Proximity routing, if it is enabled, to determine which cache group to use. (See Proximity Routing.)

    If Proximity routing is not enabled, or if Proximity routing does not return a Cache to use for the request, the Traffic Router will use the Geo Miss Default Latitude and Geo Miss Default Longitude settings of the Delivery Service to determine the closest cache group to use for the client request. (See Geolocation Based Routing.)

The following is an example of the general advanced settings:

• DSCP Edge Tag: All of the packets that are sent from the Edge cache to the client can be marked with a DSCP value. The DSCP Edge Tag setting enables you to configure what that DSCP value will be. The DSCP Edge Tag can be used by routers and other network devices to give the traffic from this Delivery Service different priority.

• DSCP Mid Tag: All of the packets that are sent from the Mid cache to the Edge cache can be marked with a DSCP value. The DSCP Mid Tag setting enables you to configure what that DSCP value will be. This tag can be used by routers and other network devices to give the traffic from this Delivery Service different priority.

• Use Content Prepositioning: Typically content is not acquired and stored on the cache until a client requests the content. However, in some situations, for example if you have content that you know is going to be very popular, you may want the cache to acquire and store the content before it is requested. This is what the Content Prepositioning feature enables you to do.

  To configure the Delivery Service to support content prepositioning, choose Yes for the Use Content Prepositioning setting. In addition, you must also configure the Ingest Manifest File URL field and the Preload On field for content prepositioning to occur. These fields are discussed below. The default for this setting is No.

  Note	The following fields are only available to edit if Use Content Prepositioning is set to Yes.

  • Ingest Manifest File URL: When you configure prepositioning, you use an Ingest Manifest file to define what content to put on the selected caches ahead of time. In the Ingest Manifest File URL field, enter the web address (URL) for the location of the Ingest Manifest file. For example, http://store.company.example/config/cdnmanifest.json.

    Note	For an example of an Ingest Manifest file and for a description of its syntax, see Example Ingest Manifest File.

  • HTTP Proxy for Ingest Manifest File URL: If the cache servers need to go through a proxy server to retrieve the Ingest Manifest file configured in the Ingest Manifest File URL field, enter the URL for the proxy server in this field.

  • Preload on: This field enables you to choose the type of cache servers that you would like preposition the content on. Your options are Edge Only, Mid Only, or Edge + Mid.

  Note	The following two fields are optional fields that you can configure for Content Prepositioning. These features require additional configuration outside of OMD Director in Traffic Ops.

  • Use Dedicated Volume: By default cache servers have two volumes:

    • One volume for live content for Live Delivery Services, which is stored in RAM

    • One volume that is typically all of the disks in the cache server, which is used for VOD Delivery Services

      Additionally, a third volume can be created that is dedicated to storing prepositioned content for a Delivery Service.

      If a third volume has been created on the cache server, the Use Dedicated Volume field points to that volume, which tells the cache server to use that volume for prepositioned content. With this field you also configure which Origin Servers in the Delivery Service you want to preposition content from. The following is the syntax for this field:

      hostname=server.company.example volume=X

      where server.company.example is the URL of the Origin Server whose content you want to preposition on this volume and X is the volume number that was created for the dedicated volume. This number must match the Preposition Volume number that was created in Traffic Ops. For example hostname=s1.company.example volume=3.

  • Cache Configuration: By default when content is prepositioned on the cache server, the content stays on the cache until the cache server needs space to hold new content. When the cache fills up and clients make new requests to the cache, the cache automatically evicts the oldest content, which is not always the behavior that you want. When you preposition content in the cache, you might want to ensure that the prepositioned content is always available and that it is never evicted from the cache. The pinning feature enables you to accomplish this.

    If the cache server has been configured to support pinning in Traffic Ops, you use the Cache Configuration field to configure which Origin Servers you will pin content for and for how long the content will be pinned. The following is the syntax for this field:

    dest_host =server.company.example pin-in-cache=time

    where server.company.example is the URL of the Origin Server whose content you want to pin and time is the length of time to pin this content. For example dest_host=os1.compay.example pin-in-cache=100d. In this example 100d means to pin the content for 100 days. For pin-in-cache you can reference “d” for day, “h” for hours, and “m” for minute. If the hostname in the Cache Configuration field matches the hostname in the Use Dedicated Volume field, content for this Origin Server will be pinned to the volume configured in the Use Dedicated Volume field.

• Session Tracking: Session tracking assigns all CDN viewers tracking values within an HTTP cookie. Those tracking values are written into the OMD Transaction Logs for further analysis.

  To enable session tracking, from the Session Tracking drop-down list choose Yes.

  Note

  Session tracking is currently only supported on Edge caches and Mid caches. Traffic Router does not support session tracking. Session tracking occurs before header rewrite. When any header rewrite rules are defined to rewrite the “Cookie”/ “Set-Cookie” field, carefully define the rule so that it does not interfere with session tracking or the Session Tracking Security Enablement feature.

• Session Tracking Query Key List: Session tracking can use either a randomly generated ID or can accept customer parameters from a URL query string. To use customer parameters, in the Session Tracking Query Key List field, enter a comma separated list of URL Query Parameters to capture in the cookie.

• Session Tracking Security Enablement: To enable the Session Tracking Security Enablement feature, in the Session Tracking Query Key List field enter key=<keyvalue>, where <keyvalue> is the secret key to use to create the cookie signature. If URL Query Parameters also need to be listed in the Session Tracking Query Key List field for session tracking, add the key=<keyvalue> at the end separated by a comma. For example: sessionId, key=mykey.

  Note	To use the Session Tracking Security Enablement feature, Session Tracking must be set to “Yes” and you must have the URL Signing feature configured. For more information on configuring the URL Signing feature, see URL Signing.

  For more information on Session Tracking Security Enablement, see Session Tracking Security Enablement.

The following is an example of the Content Preposition settings:

In addition to remapping a client request to an origin server, there may be a need to modify information in either the client request or the response header. The Header Rewrite feature enables you to define rules to modify the headers for both requests and responses. The rules that you define will determine which requests or responses will be modified, based on matching conditions, and how the header will be modified, based on the action (operator) you define.

Note	These header rewrite rules are configured on the Delivery Service and will apply to all of the Edge caches, Mid caches, or Traffic Routers that service that Delivery Service depending on the type of header rewrite rules you define.

• Edge Header Rewrite Rules: The Edge cache will modify either the request or response header, based on the rule you define. Enter the rewrite rules in the text box. To enter more than one rewrite rule, separate them by commas. Refer to Header Rewrite Rules Syntax for information on the syntax for this rule.

• Mid Header Rewrite Rules: The Mid cache will modify either the request or response header, based on the rule you define. To enter more than one rewrite rule, separate them by commas. Refer to Header Rewrite Rules Syntax for information on the syntax for this rule.

  Note	Mid Header Rewrites rules are applied based on the Origin FQDN. If multiple Delivery Services share the same origin, mid header rewrites may conflict with each other depending on the contents.

• Cache URL Expression: The Cache URL Expression field enables you to change the cache key that is used for caching a request. This enables different URLs that provide the same content to use the same cached object. The format for the entries in this field is:

  <pattern> <replacement>

  • <pattern> is a regular expression that will be applied against the incoming request URL to determine which URLs to match.

  • <replacement> is the cache key to use for the incoming request URLs that match <pattern>.

  Example:

  http://s[123].example.com/(.*) http://s.example.com.TSINTERNAL/$1

  With this example, the s1.example.com, s2.example.com, and s3.example.com domains will effectively share the same cache objects.

  Note	To enter more than one URL cache expression, enter each expression on a separate line.

• Traffic Router Additional Response Headers: The Traffic Router will add additional HTTP headers in the response to the client, based on the information you enter. In the Name field, enter the name of an additional header that you want the Traffic Routers to add and in the Value field, enter the value to assign to the header.You can enter multiple headers by clicking the + button to add a new Name/Value pair.

  Note	This settings is only supported on HTTP-based Delivery Services. You will not see it if you are configuring the Advanced Settings of a DNS-based Delivery Service.

  Note	Its preferred to configure any CORS related headers using the CORS section, instead of placing them here.

The following is an example of the Header Rewrite Configurations settings:

URL signing cannot be configured through the CDN Wizard so this section will be grayed out. After you have completed the CDN Wizard, you can edit the Delivery Service to configure URL signing. For more information, see Edit an Existing DNS or HTTP Delivery Service.

CORS enables browsers to use a predefined set of headers and methods to describe the set of origins that are permitted to access resources using a web browser. “Origin” as it pertains to CORS and the CORS configuration refers to the scope of authority or privilege used by user agents (e.g. web browser) as specified in an “Origin:” header in the requests. It does not refer to the Origin Server of the CDN.

Configure the following settings to enable and configure the CORS policies that need to be enforced in your CDN. (Media Streamer supports both simple and non-simple (preflight) CORS requests.)

Note	The CORS settings are only supported on HTTP-based Delivery Services. You will not see them if you are configuring the Advanced Settings of a DNS-based Delivery Service.

• Allowed Origins: Enter a URI that may access the resources of the Delivery Service. For example, cdn.example1.com or https://example2.com:8080. The Traffic Router compares the value in the Origin header of the client CORS request against this list. If there is a match, the request is allowed. To add additional URIs, click the Add (plus) icon. To delete a URI from the list, click the Delete (minus) icon.

• Allow Credentials: If you want the Traffic Router to allow responses to include headers that have the Access-Control-Allowed-Credentials header set to true, choose Yes.

• Exposed Headers: Enter the headers that the client is allowed to access. To add additional headers, click the Add (plus) icon. To delete a header from the list, click the Delete (minus) icon.

• Preflight Allowed Methods: Check the check boxes for the methods that the Traffic Router should allow when a client is accessing the resources of the Delivery Service. This check occurs during a preflight check.

• Preflight Allowed Headers: Enter the general headers that the client can use when making the actual request. This check occurs during a preflight request. To add additional headers, click the Add (plus) icon. To delete a header from the list, click the Delete (minus) icon.

• Preflight Max Age: Enter the length of time that a client is allowed to cache the results of a preflight request.

When you are finished editing the Advanced Settings, click Save.