Content Delivery Frequently Asked Questions

HTTP/HTTPS data delivery is supported on the following platforms:

• HTTP Large
• HTTP Small
• ADN (View FAQ)

View an overview on these platforms.

Yes. The HTTP Large platform provides the following streaming solutions:

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:

1. Decide whether content should be served from external web server(s), an Azure block blob container, or CDN storage.

   • External Web Server: Create a customer origin configuration.

     Learn more.

   • Azure Block Blob: Create a customer origin group that points to an Azure block blob container.
   • CDN Storage: Upload content to it.
2. Use your DNS service provider to modify a CNAME record. This record should point to the desired platform's CDN hostnameRefers to a system-defined hostname that is specific to your customer account and a CDN service..

   The following sample CNAME record points "cdn.mydomain.com" to "wpc.0001.edgecastcdn.net."

   Sample CNAME record:

   Name: cdn

   Value: wpc.0001.edgecastcdn.net.

3. Create an edge CNAME configuration that points the hostname associated with the CNAME record to the desired customer origin server or CDN storage.
   

   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.

4. Repeat the above steps as needed.

Learn more.

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.

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.

Learn more.

Yes. Create an edge CNAME configuration and then register a canonical name (CNAME) record through your DNS service provider.

Learn more.

Yes. Please leverage our REST API service to create an edge CNAME configuration for each desired CNAME record.

Learn more (REST API Help Center).

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.

View reference information that maps ASCII characters to their corresponding URL-encoding.

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.

Learn more.

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.

Learn more.

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.

Learn more.

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.

Learn more.

All Requests

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.

Sample dig:

Cached Content

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.

Learn how to view response headers.

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:

• Customer Origin Server: The customer origin server (i.e., web server) must be configured to reject connections when it is unable to return the requested asset.
• Asset: The amount of time an asset may be served after its TTL has expired is determined by its max-stale value. If the asset does not have a max-stale value, then it is assigned a default value of two minutes.

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.

More information:

• Troubleshooting 5xx Responses

• 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.

  Learn more.

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:

• Enable and configure compression on the desired platform through the Compression page, which can be found on the Cache Settings sub-navigation tab.
• Make sure that the request includes the Accept-Encoding header and it should be set to one of the following compression methods:
  • gzip
  • deflate
  • bzip2

The Content-Encoding response header indicates the compression method applied to the requested content. This response header is only returned for cached content.

Learn how to view response headers.

Please refer to the Edge Server Compression troubleshooting article.

Please refer to the Origin Server Compression troubleshooting article.

• Content Delivery

  • ADN
  • IPv6
  • Cache Management
  • Rules Engine

• Security

  • CDN Security
  • MCC Security
  • Origin Shield
  • Token-Based Authentication
  • Web Application Firewall (WAF)

• Streaming

  • Dynamic Cloud Packaging
• Raw Logs
• Route (DNS)
• Storage