I have an Azure web app running an Angular with NGINX inside a Docker container. This is fronted by Azure Front Door.
The Nginx config has the following at the beginning to enable compression:
server {
gzip on;
gzip_comp_level 6;
gzip_vary on;
gzip_types *;
When hitting the webapp directly, this works fine
However, when hitting the webapp via AFD, the assets aren't compressed, so it looks like AFD is doing something to decompress the assets. Caching is disabled for the entire AFD instance.
I'm not much of a frontend guy, and this work is part of a larger overhaul of the project, so any help would be appreciated. If I need to give more info, let me know.
Tl;dr: Hitting a webapp directly honours the Nginx compression configuration. Hitting the webapp via AFD does not. Why?
Azure Front Door can dynamically compress content on the edge. Caching must be enabled, and the file must be of a MIME type to be eligible for compression. Need to enable caching behavior by the time of creation “Front Door”
Please select “Use Query String” if require
refer: Troubleshoot Azure Front Door common issues | Microsoft Learn
Related
I have 3 services in monolithic architecture. They all are served by a single backend pool (kubernetes cluster). I want to enable Azure front door caching for only one of them. How can I do that?
I have tried to achieve the same by creating two routing, one for the service to use cache and another for the rest of the services, but it doesn't cache anything.
Routing1:
frontend: /api/*
backend: backendCluster
caching: disabled
Routing2:
frontend: /api/serviceToUseCache
backend: backendCluster
caching: enabled for 1 day
However, if I enable caching on Routing1, I see requests from all the services are getting cached.
Issue was caused because of the Routing1
if cache was enabled on Routing1, because of /api/* it was cached all the services.
Cache behavior can be configured in Rules Engine. Rules Engine caching configuration will always override the route configuration. When caching is enabled, the cache behavior is different based on the cache behavior value selected.
Work around:
Create a Rules engine configuration at Front Door level
Mentioned value with specific service information as mentioned in screenshot. ingore the wildcard services like api/*
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 a Web app for docker currently running django with gunicorn as wsgi server and Nginx as reverse proxy. I am not serving any static assets via Nginx and the SSL is taken care by Azure.
So my question is, if I use Azure application gateway (with or without WAF) can I remove Nginx? I don't see any use for it, unless I want to use cache, which I don't. HTTP/2 is also provided by application gateway.
Both Nginx and Azure Application Gateway act as a reverse proxy with Layer 7 load‑balancing features plus a WAF to ensure strong protection against common web vulnerabilities and exploits.
Application Gateway supports autoscaling, SSL offloading, and end-to-end SSL, a web application firewall (WAF), cookie-based session affinity, URL path-based routing, multisite hosting, redirection, rewrite HTTP headers and other features. For a full list of supported features, see Introduction to Application Gateway. Also, you're aware of application gateway limits.
Whereas Nginx provides better URL rewriting and redirecting features than Application gateway. See the feedback. With Nginx, you can rewrite the URL of a request before passing it to a backend server. This means you can alter the location of files or request paths without modifying the URL advertised to clients. You can also redirect requests.
In my opinion, if you just want to simply use for load balancing without complex rewriting the URL, it's enough to use Azure Application Gateway. For complex use rewrite cases, you can plus Nginx. Read create Nginx rewrite rules and more details here.
Go for Azure Application gateway... and get rid of Nginx. When in cloud, it makes sense to use all PaaS platform features.
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.