Troubleshooting Stale Data Delivery

Purpose

The purpose of this procedure is to troubleshoot why the CDN is not delivering the latest version of an asset.

Source

Narrow down the source of the issue by requesting the asset directly from the origin server.

Make sure that this request matches the corresponding CDN or edge CNAME URL in the following ways:

  • Relative path
  • File name
  • Case (e.g., /path/asset.htm vs. /Path/Asset.htm)

Sample CDN URL:

http://wpc.0001.omegacdn.net/000001/marketing/productX/brochure.pdf

Sample direct request:

http://www.mydomain.com/marketing/productX/brochure.pdf

Checklist:

Request the asset directly from the origin server to verify that a new version is available.

Time-to-Live (TTL)

Cached content will continue to be served to users as long as 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. is still 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.. An asset's TTL can be calculated through the following response headers:

  • Cache-Control
  • Expires

Learn more.

Checklist:

Find out whether the asset is 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. or staleIdentifies cached content whose TTL has expired. Our edge servers revalidate stale content with the origin server. This step ensures that the latest version of the requested content is served to the requester. by calculating its TTL.

  • Fresh: Purge the content in question. Check whether the new version is now being served.
    • If purging does not resolve the issue, check the following:

      Verify the URL used to purge the asset in question. This URL can be viewed from the Last 100 Purge Requests section on the Purge/Load page.
      View information on purge syntax.

      Verify that the purge has completed. The completion date/time can be viewed from the Last 100 Purge Requests section on the Purge/Load page.

  • Stale: Proceed to the next step.

Warning Response Header

Requests that result in a stale response include a Warning response header.

Checklist:

Check for the Warning header in the response provided by the CDN.

  • Header Found: Request the asset directly from the origin server to verify that your origin server returns a 200 OK response.
  • Missing Header: Proceed to the next step.

Load Balanced Web Servers (Customer Origin)

If requests are distributed to a set of web servers via a load balancer, then it is possible that the new version may not have been distributed to all servers in that load balancing configuration. Our CDN service may be requesting the asset from a server that still has the old version.

Checklist:

If requests are load balanced across multiple servers, verify that the new version of the asset is available from each web server.

POP-Specific Stale Content

Find out whether stale content is being delivered from a single or multiple POPs.

Production traffic should not be directed to a specific POP. This type of configuration will generate sub-optimal performance.

Checklist:

Request content from specific POPs and make a note of each POP where this issue is detected.