In order for the CDN to be able to serve content to end users, it must have access to a source repository where the authoritative copy of that content resides. These sources are called "origin" servers.
Origins are servers that live outside the CDN, and can belong to the customer, or to a 3rd-party storage service. Regardless of ownership, management of content on an external origin is done via clients or web services outside of the CDN platform.
One or more Origin Pull Policies (often referred to as "OPPs") are used to "bind" the origin to one or more Sites. This binding happens at a particular location in the cache, and is resolved at the time of a request.
Before an origin can be used in an OPP, they must be registered with the CDN. Origins may be configured by clicking on the Origins view on the navbar.
The origins list is shown below:
Adding New Origins
Origins live outside the CDN, and must be capable of exposing their content via standard HTTP requests.
Origins are added via the green Add Origin button on the top right of the origins list page. After creation, origins can be edited, or removed (if not currently in use).
The following table explains the usage of each field shown in the Add Origin page:
|The "friendly" name of the origin, to aid users in identifying the origin.
|A fully-qualified domain name (FQDN)
|The hostname of the origin. Any content pulled via the CDN will use this hostname when requesting content from the origin server
|A supported path
|The path on the origin server the will be used to "jailroot" any requests.
|Whole numbers larger than 0
|The port number on the origin server that will respond to HTTP requests.
|NONE or BASIC
|Whether or not the CDN should use HTTP Basic Authentication when accessing the origin server.
|Request Timeout ( in seconds)
|Whole numbers greater than or equal to 5
|The maximum amount of time that the CDN should wait for the origin server to respond to requests.
|Whole numbers greater than or equal to 0
|The maximum number of times that the CDN should attempt to request content from the origin if prior requests time out.
|Headers to add when pulling from this origin
|Text Header Fields
|The Headers to send to the origin on origin pull. Example Origin: %passThrough%
|Headers to preserve in the cache
|Text Header Fields
|The Headers to pass through from your origin to the client. Example Access-Control-Allow-Origin
For SSL origin pull the following fields can be used in addition to the above fields:
|The port number on the origin server that will respond to HTTPS requests.
|Common Name to Validate
|Common Name to use for SSL Validation. (Optional)
|Verify SSL Certificate
|Check box to indicate if SSL Certificate should be verified on Origin Pull
Origins are available for use with Origin Pull Policies, and only appear on that policy's configuration forms.
Origin location and protocol discovery are both automated for those who may not be familiar with the concept of the origin server for CDN.
While this won't always be the Origin you want to configure, we've found that this covers the single-CDN use case for most users.
How We Automatically Detect Your Origin Server
- StrikeTracker assumes that the delivery domain is currently the server hosting your content.
- It then uses DNS (Domain Name Server) to determine the path to that server.
- Next, it attempts to connect to your origin via SSL (Secure Socket Layer) on port 443.
- If the connection is successful, it suggests HTTPS as your protocol. Otherwise, it suggests HTTP.
- Lastly, it suggests the domain of the DNS Address record (or "A" record) for your Origin.
If we can't determine the location of your domain via this process, don't worry. We'll just prompt you to fill it in manually.
Likewise, if the suggestion doesn't reflect the Origin you'd like to configure, you can simply change it. It's just a little bit of magic that should make the process simpler for a large number of users.