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.
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.
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
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.
Related
I have a custom domain pointing to a static webside using Azure CDN. After a deployment my website was no longer showing up. This was because and old version of index.html was being served from the CDN itself.
I fixed it by purging the CDN manually, but this is not ideal because I frequently update the files for this website via a build process.
What is the best practice to avoid this outcome? Do I need to add a purge to the build process itself or is there a better way?
We must configure the max-age to control Cache-Control header.Azure CDN makes use of the header's duration value.
Add Cache-Control header in index.html -
public, no-cache
All Cache-Control directives are supported by Azure CDN Standard/Premium from Verizon and Azure CDN Standard from Microsoft.
In Azure Portal => Your Static Web App => Configuration => Application Settings, ads the below settings
Set the WEBSITE_LOCAL_CACHE_OPTION to Never and WEBSITE_DYNAMIC_CACHE to 0
Reference taken from Doc
Please refer Manage expiration of web content in Azure CDN for more information
I'm using Azure Storage Blobs and have Azure CDN in front of it serving static images and videos. I have been trying to get my website to use HTTP2 for a while now, but have run into issues with how Azure containerizes .NET Core applications on Linux machines. So, the website (using Kestrel), is only serving files over http/1.1 even if they're local files.
I thought that I could "offload" somethings by moving them to a storage blob container, then using Azure CDN. This article suggests that it should be available: https://learn.microsoft.com/en-us/azure/cdn/cdn-http2
Is there something else I need to configure within my CDN profile or the Storage account to enable http/2? Or is it because my server is serving it as http/1.1?
Thanks,
AJ
After some searching, I found a thread on Stack Overflow (sorry, on mobile and it's a pain to copy/paste links) about how some anti-virus softwares intercept requests to do SSL checking. Anyway, I use Bitdefender and when I went to Protection > Online Threat Prevention and disabled "Encrypted web scan" and then reloaded my domain, sure enough all traffic poured in over http2. I'm not sure why Bitdefender treated Akamai differently, but at least we know why now!
I have an Azure Media Service set up with a Premium subscription. I made an Android app which uses VideoView player and requests the multi-bitrate video files over HTTPS using the following format for asset links:
https://example.streaming.mediaservices.windows.net/c2234567-be1a-123c-ca25-e90bfca246da/1227_e3337f7-35ac-43e0-b55c-223e3333662.ism/QualityLevels(421811)/Manifest(video,format=m3u8-aapl)
Until now, I had CDN integration disabled. This worked fine and I never had issues using HTTPS.
However, now I want to enable CDN integration with default settings. When this feature is enabled, it automatically attaches the media service subdomain as a custom domain under the CDN (in this case example.streaming.mediaservices.windows.net). From what I understand, this means I should be able to continue making requests from my Android app to the same URLs as before, except now it will direct those requests to the CDN instead of the media service.
However, what I'm not sure of is whether or not I'll still be able to call those URLs over HTTPS. I see that Azure has a feature for Custom Domains with HTTPS in the works but it doesn't appear to be available yet.
So does the ability to call media service asset URLs over HTTPS carry over after CDN integration, and especially if I'm using the default media service subdomain as my custom domain?
If not, what will happen to the HTTPS calls? Will they receive no response or will they just bypass the CDN?
you should have no issues using HTTPS on CDN enabled Media Services Endpoints.
The Custom Domain HTTPS primarily refers to vanity urls like "blizz.com", which is not currently supported.
I believe in the last few days (around 4th Feb 2014), Microsoft announced CORS support for Azure Storage (link here) which is obviously a great idea.
In my case, I just wanted to find some confirmation of using a custom domain to map to azure storage which would solve an issue as follows:
Azure storage has a container with assets (images/docs etc)
I also have css/js assets there in azure storage too
Because at present the azure storage location is something like mystorage.blob.core.windows.net and my actual domain (where pages/services live) is say www.mydomain.com, I get CORS issues loading assets from a different domain of course.
So my question is if I do map a CNAME (for example assets.mydomain.com) to azure storage, will this solve the CORS related issues? Seems to me it should, however I wanted to check if others had a similar experience that they could comment on?
Thanks in advance.
You shouldn't get CORS issues loading assets, if they're just being loaded via link, script and img tags and the like. CORS only applies to AJAX requests made by JavaScript code in browsers.
Also, if the CORS rules are correctly configured on the Azure Storage account Blob service, the domain you use to address the account is irrelevant; it's the domain the current web page was served from (the Origin domain) that must be accepted by the CORS-enabled service.
So for example, if your page is served from yaysite.com, and you try to access a resource on yay.blob.core.windows.net using an XMLHttpRequest, the browser will add an Origin header to the request:
Origin: http://yaysite.com
The server at yay.blob.core.windows.net then needs to return an Access-Control-Allow-Origin header matching that to the response headers:
Access-Control-Allow-Origin: http://yaysite.com
If the browser doesn't see this header in the response, it will discard the data and the XMLHttpRequest object will trigger the error event.
Setting CORS rules on Azure Storage is described in this MSDN blog post.
As mentioned in the title above I have a cloudservice with a WebRole that runs a web app www.myappname.com. I have taken all necessary steps to enable serving of CDN content from my app using url rewrite module on IIS. This works fine but:
The requests coming in from CDN are forwarded to .cloudapp.net instead of my custom hostname binding. I cannot find any place to change this in my configuration. When I create a new CDN endpoint my options for setting the ORIGIN DOMAIN are limited to my cloud service endpoints
Say I got a custom domain name for my cloud service CDN endpoint (ex. static.appnamecdn.com). What happens when I make request with https? I don't see any place to register the "static.appnamecdn.com" 's ssl certificate. Isn't something like this required?
From the help icon on the Create CDN Endpoint screen (Azure Management Portal) I got my answer to the second point above:
If you choose to enable HTTPS for your CDN endpoint, keep in mind the
following points:
You must use the certificate provided by the CDN. Third party certificates are not supported.
You must use the CDN domain to access content. HTTPS support is not available for custom domain names (CNAMEs) since the CDN does
not support custom certificates at this time.
HTTPS is from the CDN to the client only. Requests from the CDN to the content provider (Storage Account or hosted service) are
still made using HTTP.
Regarding your first question, I don't think that is possible...Azure's CDN unfortunately is somewhat limited in its options.
As to the 2nd, as was said in the other answer, it's not possible to use HTTPS with a custom domain name :/