We are using Azure static web app with frontdoor without problems.
Now we haven an application that should be only accessible with a private link.
We add in the staticwebapp.config.json the code
"globalHeaders": {
"Cache-Control": "no-store",
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Methods": "GET, POST, OPTIONS, DELETE, HEAD, PUT",
"Allowed-Headers": "Content-Type, Authorization, X-Requested-With, X-XSRF-TOKEN"
}
to handle the CORS config. Now the problems starts. When we deploy this app, the headers are not overwritten. Sometime we see outdated headers from deployment we have done 3h ago.
We suspect there is a cache that lives 4h.
Changes in the HTML are changed immediately, but the the headers.
Note that we have type Enterprise for the static web app.
Is there a cache in place?
Can we evict that somehow?
Update: After we waited over the weekend and deploy the app several times, we had the right version deployed. Still i think this behavior is very strange.
4
After deploying the app, the HTML changes are reflected immediately, but the headers (such as CORS and Cache-Control) are sometimes outdated and can take hours to update.
- Here the issue is with the Azure Frontdoor because if you have cache or cookies logic in the backend static webapp , then you need to enable cache will creating frontdoor creation.
If you didn’t have the logic in the code you can disable the option.
- If Azure Front Door is caching the headers, you can manually purge the cache using the Azure portal or via Azure CLI:
az network front-door purge-endpoint --resource-group <your_resource_group> --name <frontdoor_name> --content-paths /*
Status:
Now, I ‘m able to run my application successfully.
Result:
1