Microsoft WAF badBot rule 100200 is not able to differentiate between real spoofed IP vs Microsoft system spoofed IPs. Since we are using CDN ahead of AFD(as it is not fully capable like Azure CDN now)There are genuine requests from Google Bot is getting blocked in Badbot rule as the requests are containing socket IP's as CDN PoP location lP's in the request along with client IP's. Hence Badbot rule detected it has spoofed requests. Since Azure CDN and AFD's are Microsoft supported products, either the rule should be able to differentiate the real spoofed IPs vs in their own products requests, else should have an option to not to forward the PoP IP's in the requests.

I tried the new Azure Static Web Apps preview for a Gatsby project of mine. I was really amazed by the simplicity of the deployment process and the speed of the web site. There was a deal breaker, though.

What really kept us from switching from Netlify to Azure Static Web Apps was the lack of control over HTTP headers. I need to be able to for example set the cache-control header on a per-file as well as per-directory basis. The same thing goes for the link header, although that would not break the website. There also needs to be an option to set other headers arbitrarily, for example security headers.

I do know, that most of those things could be done with a CDN and we have tried that. The problem with that option is, the limitation of the maximum number of rules and the number of actions per rule. It is impossible to set all appropriate security headers, while still keeping the fine grained control of caching that we need.

If or when Azure Static Web Apps gains the ability to set headers on the same level of detail as Netlify does, it will become a serious competitor to the market leader on the JAM-stack.

Here is a reference to the Netlify way of doing things. I think it is excellent in it's simplicity and could be used as an inspiration for Azure Static Web Apps.
https://docs.netlify.com/routing/headers/

I've just experienced an issue where my deployment got stuck at the "Accepted" state for 45 minutes before I decided to cancel it. The actual cause of the hang remains a mystery, but I can make an educated guess. The resource that caused the hang (I know this because it was a linked deployment deploying only an sql server with a database) was deleted along with the resource group before I tried recreating it. Deleting this resoure probably takes more time than the Azure Portal gives the impression of (as it is with several resource types in Azure). So when I try to redeploy the same resource it gets in a state where it is both deploying and deleting at the same time. But this state is not handled nor communicated to me as a user.

This is just one concrete example, but it is clear given the share amount of other issues here regarding error messages that Azure has a serious problem in that area. It would be much appriciated if work was done on this in favour of releasing new features for a while. New features are cool, but the overall experience deteriorates when the feedback we as users get is so lacking.

LUIS containers should automatically download & upgrade models from the LUIS Authoring Portal following the published slot for that specific app.

To ensure a single place to manage the published versions of LUIS Apps, either the cloud API or the container API. It should be possible that the deploy also changes the App model inside the running LUIS containers locally.

Right now in our organization we implemented a container side-car that do this in polling fashion to check if the LUIS Authoring changed the published image of the App, but it would be great if this behavior/feature was possible to be natively supported by the LUIS container image. Furthermore, the container image already needs the access to the LUIS Authoring API for billing purposes.

Universal Packages are great for storing binaries and other files needed during deployments or other custom solutions.

What's not good is that we're limited to the Azure CLI for both publishing and downloading these files. There is no other option or integration present.

The only option for automatic downloads on a new environment is to
- Download and Install/Update the Azure CLI
- Install/Update the azure-devops Azure CLI plugin
- wrap the "az artifacts universal download" command in a Powershell Script

Not only does this take forever, but it spawn many processes, downloads dynamic "package downloader" tools, write to STDOUT with progress messages that can't be disabled, and sometimes fail/throw SSL warning errors.

Please make a "managed" Powershell/.NET library to do this or even make it possible via the REST API.

Otherwise it's hard to confirm that things have downloaded, monitor the process, or create a parallelized download process.