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.
So if you decided to use Web Role for compress CDN original here are the steps to enable compression:
[Step 1] Please add the following elevated startup task in your ServiceDefinition.csdef:
<Task commandLine=”StartupTasks\ChangeIisDefaults.cmd” executionContext=”elevated” taskType=”simple” />
[Step 2] Here is the ChangeIisDefaults.cmd script as below:
%windir%\system32\inetsrv\appcmd set config -section:httpCompression -noCompressionForHttp10:false
%windir%\system32\inetsrv\appcmd set config -section:httpCompression -noCompressionForProxies:false
[Step 3] Please add the following code in your web role OnStart() event:
using (var serverManager = new ServerManager())
Configuration config = serverManager.GetApplicationHostConfiguration();
ConfigurationSection serverRuntimeSection = config.GetSection("system.webServer/serverRuntime", "");
serverRuntimeSection["enabled"] = true;
serverRuntimeSection["frequentHitThreshold"] = 1;
serverRuntimeSection["frequentHitTimePeriod"] = TimeSpan.Parse("00:00:10");
When the CDN endpoint has gzip compression enabled, in the fiddler log you will see the following header info:
Date:Tue, 12 Jan 2012 22:26:26 GMT
Last-Modified:Tue, 12 Jan 2012 22:24:15 GMT
Setting “Enable Query String” flag:
By having “Enable query string” flag set on the CDN endpoint you can assure that content will be considered new and new values in the querystring will considered new request and update the CDN with new content. This way new values in the querystring be considered new requests and using random value in the querystring, that should go all the way back to the origin server again.
If you don’t have “enable Query String” flag set then you would need to request Azure CDN team to manually purge to content as there are no customer specific API to do purge old cached CDN content.