Azure Front Door standard keeps downloading cached unmodified blobs from the blob storage origin repeatedly

Question

We have setup Azure Front Door Standard route pointing to Azure Blob storage origin where we have stored static assets. This route is enabled with caching.

 

When an asset is requested for the first time, the Front Door downloads it from the blob storage. In the blob storage, the blob corresponding to the asset has the CacheControl blob property value set to “s-maxage=60, must-revalidate”.

 

After 60 seconds, when the client asks for the same asset, the Front Door is downloading the asset again from blob storage. The asset in the blob storage is unmodified and the blob’s ETag is unchanged since the first request. Since the ETag is unmodified, we were expecting the blob storage to return 304 and the Front Door reuses the cached asset to respond to the client. However this is not happening. Looks like Front door is not validating stale asset and reusing if the origin says 304 Not Modified.

 

Is this scenario supported in Front Door Standard?

Answer 1

@Raju Kumar

Thank you for your response above. I was able to reproduce this issue at my end as well.

I spoke with the team internally and they validated that currently Azure Front Door doesn’t support revalidation based on Etag. The team is aware of the feature request, and it is in discussions stage, and we do not have a fixed ETA for it yet.

Just replying to your question above.

We are using Azure Front Door Standard. We don't see an option to set the cache behavior to Honor Origin. Do we have to set this in a rule set in order for the cache to work?

Cache Behavior option is present in the rule set, you can set this behavior for any specific route. For example, as shown below.

Hope this helps! Please let me know if you have any additional questions. Thank you!

---

​​Please "Accept the answer" if the information helped you. This will help us and others in the community as well.