Query string caching behavior "Use Query String" is being ignored in Azure Front Door

Vasily Kornienko 0

We have an Front Door serving our main website and CDN for that website.

CDN endpoint uses main website as origin.

We want to serve all javascript and css files via CDN, we put file content hash to the url parameter in order to trigger cache update after each release.

We use "Use Query String" for "Query string caching behavior" option that should query origin server for the new file version if any url parameter (in our case hash value) is changed.

What is expected: after we release new website version with new css/js content all requests to the cdn version of the updated files should be update file versions on the CDN immediately (on first request with new hash in url parameter) due to "Use Query String" configuration.

Actual behavior: after we release new css/js content for existing files and querying these files with new hash values in url parameters Azure Front Door continues to return previous file versions for some times (several hours I guess).

This is totally inacceptable as most clients will cache previous file version for the new url with new hash value.

Please fix it ASAP or we'll have to move to other service providers.

Praveen Bandaru 700 Reputation points Microsoft External Staff

2025-03-07T12:05:00.7866667+00:00
Hello Vasily Kornienko

Greetings!

When you make any changes in the backend, the front door is expected to provide stale content from the cache for a while until the cache TTL value expires.

If you want to get new content from the front door instantly, please purge the cache for the extension you are modifying.

Check the reference doc purging in Azure Front Door

You can also customize how files are cached for specific requests, including:

Override the caching behavior set by the origin.

Determine how query string parameters are used to create the request's cache key.

Set the time to live (TTL) value to control how long contents remain in cache.

When Cache behavior is set to Override always or Override if origin missing, these fields must specify the cache duration to use. The maximum duration is 366 days. This property is only set when Cache behavior is configured to Override always or Override if origin missing.

Check the document for more understanding:

https://learn.microsoft.com/en-us/azure/frontdoor/front-door-rules-engine-actions?tabs=portal&pivots=front-door-standard-premium

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Vasily Kornienko 0 Reputation points

2025-03-07T13:24:22.15+00:00

Hello Parveen,

Thank you for your comment.

Maybe my description was initially unclear, but your solution is not an option in this case. It should work with standard caching options.

Let me explain.

According to Azure Front Door caching documentation if I set "Use Query String" behavior then same file with different url parameters should have different cache key and as result - different values. "For example, the response from the origin for a request for www.example.ashx?q=test1 is cached at the Front Door environment and returned for ensuing caches with the same query string. A request for www.example.ashx?q=test2 is cached as a separate asset with its own time-to-live setting."

In our case we have a bunch of js files (as well as css), they are referenced on the main website pages as "https://cdn.example.com/file.js?v=1". If we update content of the file.js and release it then all references are updated to "https://cdn.example.com/file.js?v=2" so we expect that this url will be treated as new cache key and Azure FD will take and cache new version of the file from the origin. But it returns previous file version instead. It lasts for several hours and then takes new file content for v=2 cache key. During this two hours our clients cache invalid content on their disks. After several hours when FD updates content for v=2 clients that already cached invalid content will not change it. I think during this period FD propagates new file version among all CDN servers.

Hope I was able to explain better this problem.

So main problem here is that Azure FD caching doesn't work as it's explained in documentation (and as common CDN solutions do).

Yes, we can purge all content each time after release but it will not solve the problem because we can't synchronize the moment of release and content purging. And we shouldn't actually do it, as using full url (with query string) as cache key should solve the problem.

You also mentioned expiration of the cache TTL. But it should work for one cache key. In our case two different urls should be treated as two different cache keys with it own TTL.

As I already mentioned - this behavior is totally inacceptable.

Share via

Query string caching behavior "Use Query String" is being ignored in Azure Front Door

Your answer