Azure CDN - Enabling HTTP Compression - Hosted Web Role

Question

Has anyone successfully configured Azure CDN for HTTP compression using their hosted web role? We are having trouble compressing HTTP content at the Azure edge servers. The CDN is only caching the uncompressed version of the content.

If we hit our resource link (webresource.axd) from a non-Azure approach it compresses via gzip (using the xxxx.cloudapp.net/cdn/webresource.axd) as expected. However, as soon as we point our resource link to Azure CDN (xxxx.vo.msecnd.net), the content is served up uncompressed, despite the browser telling the Azure CDN it accepts gzip.

I posted this same issue to Azure Forums, but nobody has responded as of yet.

While troubleshooting the problem, it appears that the Azure CDN is stripping out the Accept-Encoding HTTP header. Just curious if others have had this same issue.

Azure CDN Best Practices states...

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.

What we are seeing is that the CDN is not respecting the origin Accept-Encoding, it's being stripped away.

Answer 1

It was discovered thru trial and error that Azure CDN has a current limitation that it won't pass the Accept-Encoding HTTP header unless it finds a QueryString parameter containing a compressable filename type (.js, .cs) or you are requesting a file by its original name (jquery.js, site.css, etc.).

What this means is that if you are using an AXD resource handler (WebResource.axd, etc.), the HTTP compression will not be performed. The Azure CDN will only pass the Accept-Encoding if you append a QueryString parameter with a .cs or .js extension.

We are using a custom AXD resource handler, so this was easy for us to implement. We just applied &group=core.js and &group=core.css for our combined minified resources and the compression worked as expected. It's unfortunate this doesn't exist in the current Azure CDN documentation.

In short, we had to transform our URIs from this:

https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA

to this:

https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA&group=core.js

Once the Azure CDN sees the .js in the querystring, it will return the compressed version of the resource.

Hope this helps someone else using web resources (AXDs) served up via the Azure CDN.

Answer 2

CDN picks up compression from the origin and Windows Azure Storage does not support compression directly so if you get CDN content from Azure Storage origin, it will not be compressed. So if you have content hosted at Windows Azure Storage you will not be able to have compressed content. To have compressed content, you would need to host the content at hosted service such as web role as origin. As this type of origin would be IIS based, is a supported way to use compression.

Windows Azure CDN supports compressed content over HTTP1.0, and most of the time the problem I have seen are related with having an HTTP 1.0 vs HTTP 1.1 issue. So when you request you CDN object directly from your web role via HTTP 1.0 (using the wget command) you should get compressed content if all is correct. If you get non-compressed content then you know where the problem is. Please be sure you’ve configured your application and IIS itself to deliver compressed content to HTTP 1.0 clients as well as HTTP 1.1 clients.

I have written a detailed blog entry to exactly add HTTP Compression with Azure CDN through Web role:

http://blogs.msdn.com/b/avkashchauhan/archive/2012/03/05/enableing-gzip-compression-with-windows-azure-cdn-through-web-role.aspx

Answer 3

These answers about adding .css/.js extensions don't appear to apply any more with the recent (Q1 2014) updated Azure CDN service back-end.

I ran an isolated test with a new Cloud Service Web Role project today and a new CDN instance.

I placed a /cdn/style-1.css file in my web role (single instance) and accessed it via CDN. It was not compressed. Accessing directly WAS compressed.

The fix for my Web Role serving gzip'd content was to ensure the IIS configuration option noCompressionForProxies is "false" (default is true).

This made the Azure CDN then send me down gzip'd content.

Appending css/js extensions made no difference.

Note that when testing this change, it is a host configuration change so you must restart IIS via IIS Manager (not iisreset) for it to take effect. Lastly, to test the change, be sure to create a new file (eg, style-2.css) and request that via the CDN so it will fetch it from the origin server again.