Microsoft Azure CDN Rolled Back Due to Lack of Cache Control

Last night, I turned on Azure CDN for the first time.  It worked great from a performance perspective, but I ran into a significant limitation that meant I had to roll-back and turn it off – lack of cache control.

When I launched the www.microsofttrends.com web site through Azure CDN, the home page was cached – permanently.  New blog posts weren’t showing up on the home page!

It turns out that WordPress, by default, does not include any HTTP CACHE-CONTROL settings for pages.   When launched under CDN, the home page was therefore cached without any expiry date or directive to not cache. 

There is no ability to invalidate, control or set expiry rules on cached objects within Azure CDN either through the Azure Portal or programmatically.  There also doesn’t seem to be a way to re-issue the caching directive because the page is now cached with the original content.  I tried recreating the CDN from scratch but that just recreates the end-point – the cache itself sticks around and there is no invalidation even when deleting and creating the CDN end-point.

The default time to live for Azure CDN is 7 days.  In the meantime, it appears I’m stuck and I have rolled back to the original Azure Web Site configuration, remapped my DNS entry back to the standard web site and will await until my cache refreshes!

In the meantime, there is something that we can all do – check out the Azure Feedback Forum and vote for a change to Azure CDN to provide better control over cache expiry and invalidation.  You can vote for the feature and it is already the number one request on the feedback board.  The official status for this feature is “planned” but there is no release date for the feature.  

image