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

Question

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

Vasily Kornienko 35

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 5,210 Reputation points Microsoft External Staff Moderator

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 35 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.
Venkat V 2,545 Reputation points Microsoft External Staff Moderator

2025-03-12T06:03:18.7666667+00:00

Hi @Vasily Kornienko

I just wanted to follow up and see if you had a chance to review my response to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.
Vasily Kornienko 35 Reputation points

2025-03-13T10:33:45.8133333+00:00

Hi Venkat, unfortunately I can't see screenshots in your reply (except the screenshot of the documentation).

I tried to prepare steps to reproduce the issue, but looks like it's a phantom bug, in test scenarios everything works well, but in production we face with problem.

If you update images in the post above I could compare it with our setup (but I think it will look same).

Ideally someone from Azure support team should check what's going with CDN after our new release (there will be 1-3 hours window while this bug is persisting).
Venkat V 2,545 Reputation points Microsoft External Staff Moderator

2025-03-13T13:31:31.42+00:00

Hi @Vasily Kornienko

Thanks for your reply.

I tested with other peoples, and they are able to see my images. It seems there is a network issue on your end. If the issue persists, please try clearing the cache as well.

I tried to prepare steps to reproduce the issue, but looks like it's a phantom bug, in test scenarios everything works well, but in production we face with problem.

It seems you are able to achieve the result in the test scenario but are facing an issue in the production scenario. Since there is no such mechanism, it should work in both environments. If there is an issue in production, please cross-verify the configuration of Front Door.

I hope this is helpful! Do not hesitate to let me know if you have any other questions.

1 answer

Your answer

Praveen Bandaru 5,210 Reputation points Microsoft External Staff Moderator

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.
Venkat V 2,545 Reputation points Microsoft External Staff Moderator

2025-03-12T06:03:18.7666667+00:00

Hi @Vasily Kornienko

I just wanted to follow up and see if you had a chance to review my response to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.
Vasily Kornienko 35 Reputation points

2025-03-13T10:33:45.8133333+00:00

Hi Venkat, unfortunately I can't see screenshots in your reply (except the screenshot of the documentation).

I tried to prepare steps to reproduce the issue, but looks like it's a phantom bug, in test scenarios everything works well, but in production we face with problem.

If you update images in the post above I could compare it with our setup (but I think it will look same).

Ideally someone from Azure support team should check what's going with CDN after our new release (there will be 1-3 hours window while this bug is persisting).
Venkat V 2,545 Reputation points Microsoft External Staff Moderator

2025-03-13T13:31:31.42+00:00

Hi @Vasily Kornienko

Thanks for your reply.

I tested with other peoples, and they are able to see my images. It seems there is a network issue on your end. If the issue persists, please try clearing the cache as well.

I tried to prepare steps to reproduce the issue, but looks like it's a phantom bug, in test scenarios everything works well, but in production we face with problem.

It seems you are able to achieve the result in the test scenario but are facing an issue in the production scenario. Since there is no such mechanism, it should work in both environments. If there is an issue in production, please cross-verify the configuration of Front Door.

I hope this is helpful! Do not hesitate to let me know if you have any other questions.

Answer 1

Hi @Vasily Kornienko

I have reviewed your scenario and tested the requirement in my lab.

I created an App Service with different versions in the application and attached it to Front Door. It is working as expected, fetching from the origin on the first request and serving from the cache within a minute in my case.

Route configuration

enter image description here

Orgingroup

enter image description here

Optimization

enter image description here

Optimization

enter image description here

When I change the configuration in the application, such as updating the version, Front Door requests the origin and displays the result with the new version. However, from the next request onward, it serves the response from the cache.

enter image description here

Below is the the Cache report result

enter image description here

Kindly clear the cache and cookies and test again. If the issue persists, try testing in another browser.

The default behavior of Azure Front Door is to treat it as a new asset if the URL changes within a short period of time.

User's image

Reference: Query string behavior

I hope this is helpful! Do not hesitate to let me know if you have any other questions.

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Venkat V 2,545 Reputation points Microsoft External Staff Moderator

2025-03-17T04:50:23.89+00:00

Hi @Vasily Kornienko

I just wanted to follow up and see if you had a chance to review my response to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.

Share via

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

1 answer

Your answer