CDN

Contact OnApp Support to get started and register your interest in OnApp CDN. 

New customers should register their interest by completing the OnApp CDN contact form.

 Setting up your CDN involves:

• Enabling CDN for your cloud in the OnApp customer dashboard (contact OnApp Support)
• Setting the correct permissions for CDN in your Control Panel
• Setting up edge servers in your OnApp Control Panel, and/or subscribing to servers on the CDN marketplace
• Creating CDN edge groups and assigning specific edge servers to them
• Assigning CDN edge groups to billing plans 
• Creating CDN resources
• Assign a CDN billing plan to your users

 See the CDN requirements page for more information.

 Edge servers cache web content and deliver it to website visitors. They are virtual appliances that are deployed on compute resources and managed just like VSs. You can use edge servers to sell CDN bandwidth to your end users, and/or submit the edge server to the OnApp CDN marketplace and sell your bandwidth to other hosts. You can create as many edge servers as you need and place them on different compute resources in different geographical locations, and easily broaden your CDN by combining your own edge servers with other locations on the CDN marketplace. You can even build a CDN solely with marketplace resources.

 The edge server software is a virtual appliance that works in much the same way as a virtual server template for OnApp Cloud. Setting up an edge server in your CDN Control Panel takes a few minutes.

 Edge groups are groups of edge servers – your own, and those you subscribe to from the CDN marketplace. They are usually grouped by location, so they represent a pool of servers for a given geographical area.

Edge groups are assigned to billing plans to set the prices for the bandwidth that your end users consume. The bandwidth pricing of the billing plan is the price for CDN bandwidth sold to your end users.

 A CDN resource is a specific server with content an end user wants to distribute via the CDN. CDN resources are assigned to edge groups, which determines the list of servers taking part in distributing/caching of their data.

 CDN users are managed in just the same way as cloud users. When you create a user account, you need to grant them all necessary permissions for managing CDN resources and assign the user to the appropriate billing plan.

 There are three layers: CDN edge servers (OnApp CDN Stack software) which cache content, and deliver to end users; the core CDN network (OnApp CDNaaS) which redirects content requests from end users to the most suitable edge server; and the CDN marketplace (OnApp CDN Federation) which enables you to buy CDN resources from, and sell your own CDN resources to, other hosts.

 The OnApp CDN platform currently supports HTTP Pull, Push, live streaming and video on demand.

 Setting up edge servers, managing CDN resources, managing CDN users and billing is all handled through the OnApp control panel. This is hosted on an OnApp Control Panel server.

Managing your OnApp licenses, CDN account, and using the marketplace to add PoPs to your CDN, is handled through the OnApp customer dashboard – a web-based portal that’s free to all OnApp customers.

 There is pricing for various software and service elements, although not all of them will apply to every host using OnApp CDN. Each potential element of pricing is explained below, followed by a couple of examples to show how it works.

• OnApp controller server license
  You need an OnApp controller server to host your CDN control panel and manage your edge server resources. OnApp Cloud customers can use their existing controller server (requires version 2.3 or later). New customers will need to license the controller server, which is currently priced at $100/month as part of an OnApp Cloud deployment. There is also a standalone CDN package which includes the controller server, tools and CDN bandwidth for $500/month.
  
  Please note that currently, each physical CDN location requires a separate controller server. So if you plan to set up CDN PoPs in two different datacenters, you will require an OnApp controller server in each location, with a license for each.
   
• CDNaaS traffic 
  There is a $5/TB fee for all traffic routed through the core CDN network (CDNaaS) to your end users, whether it's from your own edge servers or marketplace servers. CDNaaS is hosted by OnApp at locations around the world, and includes the advanced decision engine used to determine the most suitable edge server to deliver content to end users. 
   
• CDN Federation/marketplace 
  There is a 10% fee charged for bandwidth you sell on the marketplace. OnApp acts as a clearing house between hosts using the marketplace to buy and sell resources: using the CDN Federation/marketplace to buy and sell bandwidth is designed to be as simple and hassle-free as possible, with payments taken care of automatically.

Pricing examples
Let's say a customer buys your CDN service for website.com. How does pricing work for different types of CDN deployment?

1. You have your own edge servers, and use them to deliver 1TB of content to your customer's visitors. You would pay $5 for the 1TB of traffic routed through CDNaaS.
2. You don't have your own edge servers. Instead your CDN is built entirely from marketplace locations, which deliver a total 1TB of content. You pay $5 for that 1TB routed through CDNaaS, plus the bandwidth costs for content delivered from each marketplace location.
3. You have your own edge servers, and use them to deliver 1TB of website.com traffic. You also use another 500GB of bandwidth from the marketplace for website.com. You pay $7.50 for the total 1.5TB of traffic routed through CDNaaS, plus the bandwidth costs for traffic delivered from each marketplace location.
4. You make your edge servers available on the marketplace, and sell 1,000GB of bandwidth to other providers at $0.05/GB. You would pay the marketplace broker fee for selling bandwidth, which is 10% of the price of the bandwidth you sell: $5.
   
   
   For full pricing details please visit http://onapp.com/getstarted/pricing. Our team will be happy to help with any questions you may have. 

We do not have a pay per view solution implemented. Still, you can integrate our streaming solution into a 3rd party PPV solution. Our secure Wowza provides secure connection (RTMPE) between the viewers.

An example of setting up a RTMPE connection using a flow player: https://onapp.zendesk.com/entries/23355312-Stream-using-RTMPe

 Submitting an edge server is simply a case of ticking a box during the CDN edge server creation process in the CDN control panel. However, please note that all edge servers you submit are assessed before they are accepted into the marketplace. This helps us ensure effective CDN performance for end users, and for other marketplace users. See the CDN requirements page for more information.

When you become an OnApp CDN customer you get access to the OnApp customer dashboard. This gives you access to the CDN marketplace: you can view all CDN resources available globally, by price and location, and add PoPs to your own CDN as required. Once you’ve added a PoP you’ll be able to see it in your control panel along with your own edge servers, if you have them. The dashboard also lets you manage various other aspects of your CDN, CDN account and OnApp software.

 Edge servers you subscribe to from the marketplace are usually available in a couple of minutes.

 To use the OnApp CDN marketplace you need a minimum of $200 in your CDN account, which you manage through the OnApp customer dashboard. Funds are deducted automatically when bandwidth is used from CDN resources you’ve selected from the marketplace, or when your own edge servers send traffic through the CDN. The same account is used to store revenue you generate by selling bandwidth on the marketplace. OnApp acts as a clearing house for your CDN purchases and sales.

 The following limitations are known when configuring a CDN Resource.:

• You can create up to 100 rules per resource 
• You can set up to 100 actions per rule
• Values can be up to 1000 characters long
• Rule processing ends after the first match
• You can set the rules for HTTP Pull and HTTP Push resources

 It is up to individual hosts to set their own pricing. There is, however, a ceiling price for CDN bandwidth in certain regions:

 Token authentication helps to protect CDN streams from being snitched. Similar to HTTP URL signing, this feature allows customers to enter a secret key during setting up a CDN resource. Then, customer can use secret key, along with expiry date and allowed/blocked referrer site to generate the token from a script.

Below there are some errors you may encounter while setting up a connection between OnApp and Identity Provider and how to solve them:

• missing name_id - make sure that you set up an email for a user on IdP
• fingerprint mismatch - ensure you are using an appropriate certificate or fingerprint. Note, the certificate takes precedence on the fingerprint if both are indicated

Currently, we do not provide this option on both user and CDN resource levels. You may achieve the same by using the API request to suspend a CDN resource.

Currently OnApp does not support this feature.

The Entity DNS Record Already Exists for Key error appears due to the same record both in CNAME and MX types.

Currently, we do not support the change of SOA. If you want to change it because of a warning in DNS monitoring reports, please note that there is no violation of any technical specification by the increment-by-1 serial number scheme we use. The scheme does not limit our customers to up to 100 updates per day.

To have your assigned NS IPs retrieved, enable the Display infoboxes option, and then you can copy them at the DNS Setup page.

To enable the Display infoboxes option:

1. Go to your Control Panel > Admin > Users menu.
2. Click the Actions button next to the user for whom you want to retrieve IPs and select Edit.
3. At the User Profile page, move the Display infoboxes slider to the right.
4. Click Save.

To retrieve your assigned NS IPs:

1. Control Panel > Admin > Settings menu.
2. Click the DNS Setup icon.
3. Copy your assigned IPs from the infobox.

Environment

OnApp 6.0.0 (and later)

Answer

Some of the image files are not recorded in CDN due to image/javascript lazy loading. Therefore, the accelerator does not rewrite them.

Environment

OnApp 6.0.0 (and later)

Answer

Some images or thumbnails can be missing after acceleration. In most cases, it happens when a website generates an image on the fly via JavaScript libraries.
It is not compatible with CDN and can cause image loading failure after acceleration.

When the origin responds with one of the following HTTP error codes:

• 500
• 502
• 503
• 504

and the content is still in cache, the edge server provides the stale content for the requester. It generally improves user experience for the end user.

Currently, the Custom Error Page feature is not available in CP UI. You can send a request to support@onapp.com and ask for it based on different error codes (e.g. 404, 501, 502, etc.).
The following information is required:

• CDN Resource ID
• Error Code
• HTML file which reflects the error code

By default, OnApp CDN edge servers treat an entire URL as a unique cache. Therefore, changing a query string in a URL is treated as two different caches.
Examples

• http://cdn.example.com/test.png?121124234
• http://cdn.example.com/test.png?342345553

To resolve it:

1. Go to your Control Panel > CDN > Resources menu.
2. Click the Actions button next to the CDN resource's label that you want to edit and then select Edit.
3. On the page that appears, move the Advanced Settings slider to the right.
4. In the Proxy cache key dropdown list, select $host$uri instead of $host$request_uri.

If an external publishing point is used to restream your client's 300 streams, there is no need to create 300 CDN resources if these streams are coming from the same mail URL.
For example, your client has the following streams:

rtmp://domain.com/stream1 
rtmp://domain.com/stream2 
rtmp://domain.com/stream3

For this, create a live streaming CDN resource in Control Panel and set the external publishing point as rtmp://domain.com.
Refer to the instructions to get the CDN streaming URL.

HTTP Pull with enabled pseudo streaming works with a Flash player that supports pseudo-streaming, as well as with Apple and Android using progressive downloading (byte-range seeking).
VOD Pull works with any Flash players via RTMP. Specialized Flash clients require HDS (HTTP Dynamic Streaming). It works with Apple and Android using Apple via HTTP or Android via RTSP.
However, VOD Pull is more efficient comparing to HTTP Pull pseudo-streaming:

• The Pull from origin to edge server - Wowza cache module only requests the parts of a video, which are requested by the client.
• Because Nginx downloads everything from the beginning, scrubbing is slow when a video file is not available in Nginx cache.
• RTMP and RTSP use single connection. Thus, scrubbing is very fast comparing to pseudo-streaming which has to establish new HTTP connection while scrubbing.
• RTMP only buffers a fixed amount of data determined by the Flash player. Pseudo-streaming is as fast as the visitor's port speed.

The downside of RTMP is that a Flash player doesn't buffer the video to the client's disk. Therefore, when replying a video, it will be downloaded again.

• Cached data - the content is available and cached in the edge server upon visitors request.
• Non-cached data - the content is not available/cached in the edge server upon visitors request. The edge server pulls the content from the origin.

The statistics include cached and non-cached data between an edge server and end users only, and not the data between the edge server and the origin.

You can check if your file is cached with the command-line tool curl:

curl -I [url]

Example

[cs.yap@onappvpn ~]$ curl -I http://images.z22se.org.uk/Z22SE_logoUIX.png
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 24 Oct 2013 08:05:39 GMT
Content-Type: image/png
Content-Length: 9049
Connection: keep-alive
Vary: Accept-Encoding
Last-Modified: Tue, 20 Aug 2013 09:41:50 GMT
X-Age: 512353
X-Edge-IP: 173.244.216.19
X-Edge-Location: Washington, US
X-Cache: HIT
Accept-Ranges: bytes

That means http://images.z22se.org.uk/Z22SE_logoUIX.png is cached in the Washington Edge because of X-Cache: HIT.
If the result is X-Cache: MISS, it means the file were not cached in the CDN PoP. To resolve it, curl one more time so that result is X-Cache: HIT. If you see X-Cache: MISS again, it means the file will not be cached in the CDN PoP at all. In this case, check the setting of the Cache-Control header.

Use the same command again as in the following example:

[cs.yap@onappvpn ~]$ curl -I http://data.z22se.org.uk/Z22SE_logoUIX.png
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 24 Oct 2013 08:26:48 GMT
Content-Type: image/png
Content-Length: 9049
Connection: keep-alive
Last-Modified: Tue, 20 Aug 2013 09:41:50 GMT
Expires: Fri, 22 Nov 2013 16:44:54 GMT
Cache-Control: max-age=2592000
Cache-Control: public, must-revalidate, proxy-revalidate
X-Age: 56514
X-Edge-IP: 173.244.216.19
X-Edge-Location: Washington, US
X-Cache: HIT
Accept-Ranges: bytes

It means that the file will be cached for 2592000 seconds because of Cache-Control: max-age=2592000. If Cache-Control: max-age= No Cache, the file will never be cached in our CDN PoP. 

Wowza logs are located under /home/wowza/logs in streaming edge servers.
If you would like have SSH access to your own edge servers, submit a request to OnApp Support.

To curl a CORS header in a live streaming M3U8 file, use the following syntax:

curl -I http://<id>.r.<domain>/<path>/<file>.m3u8

It is not recommended to distribute your website contents using OnApp CDN with an origin from a third-party CDN provider due to following possible reasons:

• The purge functionality doesn't work because the origin CDN is still storing the old cache.
• Custom cookies configured by the origin CDN can cause failure to effectively store the cache on OnApp CDN.
• Setting security on OnApp CDN and origin CDN may cause failure to effectively store the cache and lead to a poor cache hit ratio.

To submit a browser network console trace to troubleshoot CDN performance or content errors:

1. Open the Google Chrome browser.
2. Press Ctrl+Shift+I to open the browser console.
3. Click the Network tab and select the Disable cache checkbox.
4. Enter your URL in the address bar and press Enter.
5. Right-click anywhere in the console and select Save all as HAR with content.
6. Attach the saved .har file to the request.

If your CDN site is not caching, use the curl command. If the result is X-Cache: MISS, it means that the files were not cached in the CDN PoP.
When your CDN URL is not caching, it can be due to the following:

• Origin Cache-Control HTTP header is set as No-Cache.
• If cookies are enabled, at the Edit CDN Resource page, move the Advanced Settings slider to the right, and then move the Ignore Set Cookie slider to the right.
• The Expires header comes before the Cache-Control header. Our system honors the order of the web header. If the Expires header is set to a past date, the content will never be cached.
• If you get a 301 or 302 redirect when performing curl -I in your CDN URL, remove the redirect from the web origin or use the IP origin if the redirect rule did not apply to the IP.

In your Linux command prompt, enter the following command:

curl -I mycdnurl.com

Example

[cs.yap@onappvpn ~]$ curl -i -vvv -o /dev/null -s

http://cdn.onapp.com/files/datasheets/onapp_cdn_datasheet_0313.pdf

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 09 Dec 2013 09:24:15 GMT
Content-Type: application/pdf
Content-Length: 694694
Connection: keep-alive
Last-Modified: Mon, 18 Mar 2013 20:11:40 GMT
Cache-Control: max-age=2592000, public
Expires: Tue, 07 Jan 2014 12:42:29 GMT
Vary: Accept-Encoding,User-Agent
X-Age: 74506
X-Edge-IP: 37.220.34.244
X-Edge-Location: Amsterdam, NL
X-Cache: HIT
Accept-Ranges: bytes

CDN can be enabled for a full OnApp license only. For more details, contact our sales team at following email address: sales@onapp.com.

The three-IP-address requirement is a security measure for your CDN edge server. The edge server needs multiple IP addresses to produce a unique combination of IPs which is given to each user. If there is a DDoS attack on any of its IP addresses, it can be localized and does not affect the rest of the users, as they continue to connect to the same edge server but via the other two IP addresses.

When a DDoS attack is detected on our clients' edge servers, we recommend our client to shut down them temporary and null route the IP to avoid further attacks. You may bring your server back online when you are comfortable. When a CDN site is undergoing a DDoS attack, we suspend the CDN site as soon as we detect the attack.

Refer to the following example when configuring bonding:

iface bond0 inet static 
        address x.x.x.x 
		netmask x.x.x.x 
		gateway x.x.x.x 
		slaves ethX ethY 
		bond_mode 4 
		bond-lacp-rate 1 
		bond_miimon 100 
		bond_downdelay 200 
		bond_updelay 200 
		bond_xmit_hash_policy layer3+4

To change the price of a CDN PoP:

1. Go to your OnApp Dashbord > Licenses > license’s label.
2. On the page that appears, click the CDN Locations tab.
3. On the following page, click the Edit button next to the required location.
4. On the page that appears, in the Price per GB (USD) field, edit the price.
5. Click Save changes.

If you delete a streaming edge server, the Wowza licensing server will reduce the number of your Wowza servers accordingly.

Our streaming servers are installed with the Wowza solution. The Wowza software does not include a hard limit on connection. However, JAVA is limited to 5 Gbps per instance without tuning at the OS level. Go to wowza.com/forums for more information.

Once files are uploaded to the origin of a storage server, they are populated to the CDN edge servers depending on the frequency such files are requested during a specific period of time. If your files are frequently requested, they are replicated to more CDN edge servers faster than the rest of the files. Anyway, the files, which are not frequently requested, will be replicated to the CDN edge servers too, but it may take a longer time.

Currently, the maximum supported size of an HTTP header is up to 8 KB.

OnApp CDN supports ETag headers. It is enabled automatically on all CDN edge servers. As long as the ETag header is used on the web origin server, CDN edge servers inherit the header and honour it. There is no additional setup required in the CDN resource. Go to www.bizcoder.com/using-etags-and-last-modified-headers-to-improve-performance-with-http-conditional-requests, en.wikipedia.org/wiki/HTTP_ETag, stackoverflow.com/questions/824152/what-takes-precedence-the-etag-or-last-modified-http-header for more details.

The ASN whitelist feature is applicable to routing rules for enterprise package. Contact OnApp Support for more details.
Edge servers can accept HTTP requests from all IP ranges by default. If you set a rule for edge server 1 to accept IP ASN XXX only and set a rule for edge server 2 to accept IP ASN YYY only, it is not required to set a rule for edge server 3:

• If a visitor's IP range comes from ASN XXX, it is redirected to edge server 1 or edge server 3, as both of them can accept ASN XXX.
• If a visitor's IP range comes from ASN YYY, it is redirected to edge server 2 or edge server 3, as both of them can accept ASN YYY.
• If a visitor's IP range comes from ASN ZZZ, it is redirected to edge server 3 only, as edge server 3 can accept any ASN.

OnApp CDN supports HTTP/2. This setup is enabled automatically on all our CDN edge servers. To make use of HTTP/2, a CDN resource must deliver the content via HTTPS, which can be enabled with the Shared SSL *.r.worldssl.net or Custom SNI SSL. When serving the CDN content through HTTPS, there is no further setup of the HTTP/2 header on the origin web server.

Our CDN system checks the Last-Modified response HTTP header of a CDN URL and compares it with the cache on an edge server. It is called the If-Modified-Since validation check. If the returned header gives the same result Last-Modified as the cache does, the file caching will continue, although the cache expiry time is reached.

OnApp does not support proxying with the WebSocket protocol.

It takes time for Wowza to transcode RTMP to HLS/HDS. Thus, there is a 30-second to 60-second delay/buffering when watching a stream or video on iOS devices.

You can determine the IP of your visitor in OnApp CDN by inserting X-Forwarded-For in the HTTP header of your resource.

The CDN cannot override the header of an origin, as we always honor the origin HTTP headers. For example, the cache expiry settings, which you set at the CDN resource level, do not override the max-age set in the origin Cache-Control header.

A .zave file is served as a text/plain. That's why browsers are not able to determine the file size during download. If you are not able to rename the file, change the Content-Type header on the origin server. It happens because our edge server compresses the following Content-Types:
text/plain
text/css
application/x-javascript
text/xml
application/xml
application/xml+rss
text/javascript
application/json
application/javascript
image/svg+xml

If you have more than one license on Dashboard, you can add a CDN location for each of the licenses and set a price. However, the licenses cannot share the same CDN location to avoid system conflict. If the clouds from multiple licenses are from the same location, you can add a CDN location which is near to the other one as an option. 

If you cannot add a CDN resource in Control Panel, check the following:

• Have you assigned any edge group to the user's billing plan?
• Have you given permission (through their role's permissions) to the user to create CDN resources?

Certain requirements should be met to create CDN resources. Take note of the following:

• To create a VoD/Live Streaming CDN resource (regardless of a Pull or Push type), a streaming location is required in the edge group of the user's billing plan.
• To create HTTP Push and VoD Push CDN resources, you need an HTTP CDN Storage Server and an Streaming CDN Storage Server respectively.

A CDN edge server send an HTTP Via header with the value in the following format: {edge.id}.edge.worldcdn.net. As an {edge.id} is dynamic, it should wildcard.

The supported size of an HTTP header is 16 K (4 slots). When the size of the header is bigger than 16 K:

• The request line cannot be bigger than the size of one buffer (16 K). If the client sends a bigger header, Nginx returns a 414 Request-URI Too Large error.
• The longest header line of a request must not exceed the size of one buffer (16 K). Otherwise, the client receives a 400 Bad Request error.

Check your CDN resource redirection result at http://debug.onappcdn.com/dns/. All locations, which a CDN resource can access, will be shown in the debugger result. 
Check the following:

• Have you added the new locations to the correct edge group?
• Has the edge group been assigned to the correct billing plan?

The following HTTP resource API requests are provided by OnApp CDN:

You will see a request header to your origin server (HTTP resource) for connection coming from edge servers.
Example

X-Forwarded-For: 192.168.12.132
Via: 867891234.edge.worldcdn.net

We have the following policy for CDN maintenance notifications:

• 24 hours beforehand if the maintenance involves short downtime (less than 15 minutes) on API or back-end configuration. It includes the create/update/delete action that cannot be performed in Control Panel. However, CDN delivery is not affected and the website continues to serve.
• One week beforehand if the maintenance involves downtime on CDN delivery. It occurs rarely.

Web browsers do not permit fonts to be loaded from a different domain unless CORS headers are setup to allow it.

To enable permissive CORS headers for fonts:

1.  Add the following to your webserver configuration:

Apache

<FilesMatch "\.(eot|otf|ttf|woff|svg)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>

Nginx

location ~* \.(eot|otf|ttf|woff|svg)$ {
add_header Access-Control-Allow-Origin *;
}

     2. Check if the headers are returned by the origin server as expected.

     3. Purge the fonts from the CDN, so that the headers are refreshed.

Please note that for a Push resource, you need to add it in Control Panel. Refer to the Create HTTP CDN Resource page. 

If a CDN site is still serving traffic after it has been deleted, it may caused by the combination of DNS cache + CDN Resource Delete Configuration.

DNS Cache

Once you suspend/remove a CDN resource or update an edge group (change from location A to B), our DNS redirector stops redirecting all new user requests to the CDN edge server A. However, some visitors' requests will still manage to hit to the CDN edge server A due to their ISP DNS cache. The time for DNS cache varies among different ISP DNS. In this case, visitors (from the cached DNS network) will hit the CDN edge server A directly without going through the CDN redirector.

CDN Resource Delete Configuration

Once a CDN resource is suspended/removed or an edge group is being updated, our system does not delete the CDN resource configuration on the CDN edge server immediately. The removal will be completed in 24 hours. It is related to DNS cache as mentioned above.

If a PoP is paused, it still be shown as active inside OnApp indicating that the subscription is active. As a paused PoP is supposed to come back online quickly, it will not appear in OnApp Debugger and clients will not receive any notifications. 

OnApp CDN handles requests for partially cached content in the following way:

1. Uncached range requests starting from 0 are filled from the origin starting from 0. The response is cached.
2. Uncached range requests starting from > 0 are proxied to the origin with the requested range. It means that the uncached range requests can always be served immediately without waiting for the file to be fully loaded. However, this partial response from the origin is not cached.
3. Cached range requests are served from cache returning the requested ranges.

In all cases, the end user gets a 206 Partial Content response.

An SWF/Flash file may not be loaded properly via a CDN network because a Flash player checks permission to the secure content loaded by the SWF file that originates from other domains. To resolve it, a crossdomain.xml is required on the origin server.

Create a default allow rule, as in the example below:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

Technically, it is possible to create the second CDN URL from the OnApp CDN to deliver content using a Cloudflare URL as an origin. But our clients are not recommended to serve their web content using a CDN-over-CDN scheme, as these multiple layers of redirection may degrade the website performance and increase the complexity of investigation when issues occur.

Additionally, by using the Cloudflare URL as an origin, the Ignore-Set Cookie feature will be set up for your CDN, as the Cloudflare sets specific cookies in the web header. Without ignoring the cookies, our CDN will treat the same file as unique. Therefore, it will impact the cache hit ratio.

If you are selling a location in CDN federation and wish to change it to another one, contact OnApp Support. Our engineer will verify the location of your edge server on the network. If the location changes reflect the network result, it will be changed.

Notifications are sent to the respective buyer or seller in the following cases:

• Price changes for marketplace PoPs.
• A new PoP/location is available in the marketplace.
• Seller removes PoPs which are currently subscribed by buyers.
• Seller sets private pricing for buyer.

To disable the notifications, contact OnApp Support.

If you switch from one OnApp empowered CDN provider to another and wish to use the same CDN resource hostname or DNS zone (while having the old record kept in the old CDN provider and being unable to delete it), follow the steps below:

  1. Domain Ownership:

• Add the following TXT record on the root domain of the CDN hostname or the DNS Zone that you wish to remove from the old provider: ONAPP OWNERSHIP CHANGES
  OR
• Create a new CDN resource in the new provider’s panel with the same root domain and configure a CNAME record (it is only applicable to a CDN resource).

   2. Submit a ticket and specify that the issue is related to reclaiming of a CDN resource or DNS zone.
   3. OnApp Support will accept the request and contact the old provider to remove the CDN resource or DNS zone within 24 hours.
   4. CDN admin will remove the CDN resource/DNS zone from back end if the removal was not completed by the old provider within the given time frame.

Do not impose any firewall rules on your Control Panel server and edge server as it affects:

• CP communication with CDN core
• CP API calls that include resource creation, purge, prefetch, etc.
• Edge servers when serving CDN resource content