Show search and navigation.
Yes. The HTTP Large platform provides the following streaming solutions:
This streaming solution is designed to dynamically provide viewers with high quality live or on-demand streams with minimal buffering/stuttering. This solution ingests a RTMP feed and is compatible with standard HLS and DASH media players.
This streaming solution makes sequential byte-range requests to stream on-demand content over the HTTP Large platform.
Use the CDN to deliver data over HTTP from CDN storageRefers to our storage solution. Store content on our servers to ensure data availability and fast data delivery. and/or customer origin serverRefers to a web server external to our network that will serve as the source from which content will be delivered. This type of web server must be defined in a customer origin configuration.s.
The recommended method for setting up data delivery is to:
Decide whether content should be served from external web server(s)
The following sample CNAME record points "cdn.mydomain.com" to "wpc.0001.edgecastcdn.net."
Sample CNAME record:
Leveraging a CNAME record and an edge CNAME configuration allows site content to instantly flow through the CDN without requiring the modification of existing links to point to our CDN.
An asset is typically a file (e.g., MyNotes.txt, Presentation.ppt, Document.doc). However, it also includes dynamic content. For example, a web application may generate dynamic pages based on a user's web session. Each request will generate a new asset that can be cached on our edge servers.
An edge serverThis type of server is located near the edge of our network where its close proximity to your end-users allows it to deliver data more quickly than normal Internet communication. It is responsible for handling requests and caching assets. is a type of server. Each point-of-presence (POPIdentifies a location on our network through which users can request and receive content.) contains many edge servers. Each of these servers may cache content and serve it to your clients.
This term refers to a server that can honor requests. Each type of origin server is defined below.
A customer origin configuration may point to a server that is external to our CDN network. This type of configuration allows our CDN to request data from that server.
A customer origin group may point to an Azure block blob container. This type of configuration allows our CDN to request content stored within that Azure block blob container.
This type of origin server refers to dedicated storage servers within our network. These servers are hosted and maintained by the CDN. Each customer account can store data on these CDN storage servers.
By default, our CDN service only supports GETThis popular request method is used to retrieve information from a server. A GET request informs the server that the asset at the requested URL should be delivered to the requester. requests. It proxies all other request methods to the customer origin server.
Yes. Create an edge CNAME configuration and then register a canonical name (CNAME) record through your DNS service provider.
Yes. Please leverage our REST API service to create an edge CNAME configuration for each desired CNAME record.
After which, leverage your DNS service provider's developer tools to automate the modification of a CNAME record to point to a CDN hostname.
CDN and edge CNAME URLs only support the ASCII character set.
Use a client-side script to convert non-alphanumeric characters into valid ASCII format.
If a freshIdentifies cached content that can be served directly by an edge server without requiring revalidation with an origin server. It also indicates that the cached content's TTL has not expired. version of the requested content is not found, our edge servers will forward all elements of a request (i.e., HTTP method, URLRefers to a CDN or edge CNAME URL. If the request includes a query string, then it will also be forwarded to the origin server. , headers, and body) to an origin server. However, certain request headers are reserved for system-use and may be overwritten.
HTTPS requests over the HTTP/2 protocol automatically reap performance benefits for the communication between the client and the edge of our network. Specifically, it diminishes user-perceived latency, network usage, and server resource usage.
Requests that result in a cache missIndicates that the requested content could not be served immediately from the edge of our network because it either hasn't been cached or its TTL has expired. This type of request is forwarded to an origin server. will be forwarded to an origin server using the HTTP/1.1 protocol.
Standard HTTP requestsRefers to requests that have not been encrypted by TLS. will be served via the version of the protocol (i.e., HTTP/1.0 or HTTP/1.1) defined in the request.
Yes. However, it requires activation. After which, a client must include the following headers in the request:
Contact your CDN account manager to activate WebSocket protocol support.
By default, our edge servers will forward all response headers provided by the origin server. It will also include additional response headers that describe the response and define the local cache policy.
Perform a dig on the requested hostname to find out whether the request was served by our network. The answer section will reveal the DNS record corresponding to that hostname.
If the requested content is served directly from the edge of our network, then the Server response will indicate the platform and the POP location from which the content was served.
Content will continue to be served when your customer origin server is inaccessible when the POP closest to the requester contains a cached copy of the requested content and its TTLTime to Live. Refers to the amount of time that a cached asset is still considered fresh. Our edge servers will continue to serve a cached version of an asset while its TTL has not expired. An asset's TTL is calculated by the Cache-Control and Expires headers associated with the response sent by the origin server. has not expired.
If the requested content's TTLTime to Live. Refers to the amount of time that a cached asset is still considered fresh. Our edge servers will continue to serve a cached version of an asset while its TTL has not expired. An asset's TTL is calculated by the Cache-Control and Expires headers associated with the response sent by the origin server. has expired, then it will continue to be served provided that both of the following conditions are met:
A request for content that occurs after max-stale has expired will cause an edge server to forward the request to your customer origin server. If your customer origin server is still inaccessible, then it may return a 5xx response code. By default, our edge servers forward this response code to your clients.
If you have enabled Origin Shield on the customer origin server hosting the requested content, the asset will be served from the POP corresponding to the region from which the request originated (as long as its TTL has not expired). After the TTL expires, the POP will forward the request to the origin shield server. The origin shield server will handle this request in the same manner as a POP.
There are many advantages to using Origin Shield. In this particular case, Origin Shield provides a cache layer between our POPs and your customer origin server. If a customer requests content from your customer origin server, the default behavior is to cache it on an origin shield server. This allows content to be served from the origin shield server instead of from a customer origin server. This means that although the requested content may not be cached on a particular POP, it will probably be cached on the origin shield server. This reduces the number of customers that will experience service disruption when your customer origin server becomes unavailable.
Origin Shield is an additional service that can be added to your CDN account. For more information, please contact your CDN account manager.
By default, all HTTP connections from the client to the server are persistent. A client should assume that the connection is persistent unless the response specifically states otherwise.
The Connection: Keep-Alive header will not be included in the response for persistent connections.
Only requests that contain an Accept-Encoding request header will be compressed. A request may either be compressed by a customer origin server or by our edge servers.
If you would like our edge servers to serve the requested content in a compressed format, then you will need to:
The Content-Encoding response header indicates the compression method applied to the requested content. This response header is only returned for cached content.
Please refer to the Edge Server Compression troubleshooting article.
Please refer to the Origin Server Compression troubleshooting article.