• 4 min read

Best Practices for the Windows Azure Content Delivery Network

Excerpted from: https://msdn.microsoft.com/en-us/library/gg680299.aspx How can I use web.config to manage the caching behavior in hosted-object CDN delivery? The Windows Azure Content Delivery…

Excerpted from: https://msdn.microsoft.com/en-us/library/gg680299.aspx

How can I use web.config to manage the caching behavior in hosted-object CDN delivery?

The Windows Azure Content Delivery Network (CDN) honors the cache control headers provided by the hosted service. If the content is provided by a web role, this is controlled by IIS. Cache control headers for static content can be customized by changing the element of the element in the web configuration.

For example:

The following configuration sample adds an HTTP “Expires: Tue, 19 Jan 2038 03:14:07 GMT” header to the response, which configures requests to expire years from now.




            httpExpires=”Tue, 19 Jan 2038 03:14:07 GMT” />



For ASP.NET pages, the default behavior is to set cache control to private. In this case, the Windows Azure CDN will not cache this content. To override this behavior, use the Response object to change the default cache control settings.

For example:



Settings contained in the root location of your origin will be inherited to all subfolders.  Note that you can also place a web.config file in any sub-directory within origin to control individual configuration settings appropriate to the given sub-directory tree. 

You should only utilize a web.config file to add MIME types that are not IIS defaults.  If you use a web.config and redefine a standard MIME type IIS could return a 500 (see:  https://blogs.msdn.com/b/chaun/archive/2009/12/04/iis7-error-cannot-add-duplicate-collection-entry-of-type-mimemap-with-unique-key-attribute-fileextension.aspx).  As a best practice, you generally only need to set a MIME type if try to deliver a new file type and are receiving a 404.  E.g. test any new file types for delivery and, if required, add a mime type prior to generally publishing any links.

Are there any best practices for managing different CDN environments in my Windows Azure project?

For example, if you want to have a separate CDN endpoint configured for a test environment vs. production in the same project, we recommend putting the different domains in a configuration setting (ServiceConfiguration.cscfg), since those values can be changed at runtime. However web.config is also an acceptable repository.

What’s the best way to ensure that my content is fresh?

Setting good cache expiration headers is the simplest way to ensure freshness, control costs, and give your clients the best performance. 

See https://msdn.microsoft.com/en-us/library/gg680305.aspx

Can I use different folder names in the Windows Azure CDN?

Yes, absolutely. The Windows Azure CDN simply reflects the URL structure to your source content; you can nest it as deeply as you need.

For hosted-service object delivery as of SDK 1.4, you are restricted to publishing under the /cdn folder root on your service.

How are query string parameters used in caching?

For hosted-service object delivery, you can toggle this behavior in the Windows Azure Developer Portal when you enable CDN on a hosted service. Enabled means that the entire query string will be used as part of the object’s cache key; that is, objects with the same root URL path but with different query strings will be cached as separate objects. “Disabled” means that different query string values are ignored and only the root URL path is used as cache key so different query strings are treated as the same object and only cached once.

In blob storage origin, query strings are always ignored. In particular, shared access strings cannot be used to enable CDN access to a private container.

What are examples of how I could use HTTPS delivery?

HTTPS delivery on the Windows Azure CDN is used to deliver publicly available objects that must be contained within a secure session. For example, a shopping cart may use many “chrome” objects including graphics, buttons, static scripts and other reusable elements; in a secured shopping-cart page flow, these objects must be delivered via HTTPS to avoid browser warnings.

How does the Windows Azure CDN do replication?

There is no replication. File load in the Windows Azure CDN is “pull”. Files are uploaded to a single location (e.g. the origin) and pulled into cache nodes based upon requests from clients.

What nodes of the Windows Azure CDN is my service deployed to?

When you deploy to the Windows Azure CDN, you are automatically “deployed” to all of our locations, and you are added to each additional location as it comes on line.  You do not have to do anything to start utilizing a “new” CDN node. The Windows Azure CDN employs anycast to route the end user to the closest node.

What are best practices for byte range requests in the Windows Azure CDN?

Do not put your signatures/table-of-contents/catalog at the end of a large file and then use a byte-range GET to retrieve it.  This will cause sub-optimal performance.  A signature file should be placed in the beginning of a file, or ideally in a separate file.

How does the Windows Azure CDN work with compressed content?

The Windows Azure CDN will not modify (or add) compression to your objects. The Windows Azure CDN respects whatever compression is provided by the origin based on the “Accept-Encoding” header. As of 1.4, Azure Storage does not support compression. If you are using hosted-service object delivery, you can configure IIS to return compressed objects.

How can I purge or invalidate content in the Windows Azure CDN?

As of 1.4, no purge function is available. This feature is under development. The best freshness control is to set good cache expiration headers as described in this document and the Windows Azure CDN documentation on MSDN.

Example Problem Report: “The CDN isn’t getting fresh objects,” or, “The CDN seems to be caching objects for 72 hours”

You’re not emitting a Cache-Control header, or a value that is meaningless to our CDN and it therefore ignores it and will cache up to 72 hours.

Cache-control headers should be “public” and have a value greater than 300, or the CDN will ignore it.  If you’re intentionally emitting a Cache-Control value < 300 then that content arguably shouldn't be on the CDN in the first place.

Please adjust your origin expirations to better values, as described here: 

How often does the CDN refresh objects from origin?

It depends on the object’s cache-control headers (or lack thereof), object popularity, parent cacheability and edge utilization.  It will hit origin at least once per node per freshness window, and follow up with If-Modified-Since requests upon refresh.

If no Cache-Control header is set, please see the “72 hours” question above.