Azure CDN not serving full mp3; Direct blob storage works fine

Eben Freeman 0

Azure CDN is not serving a full mp3 file to the browser, the media player (video.js) stops and spins after a few min. This is a repeating daily issue that did not happen 6 months ago. Direct blob storage works fine.

Both CDN and blob storage requests return the same '206 Partial Content' and include the same request and response headers:
Request:
Range: bytes=0-

Response:

content-length: 26030624

content-range: bytes 0-26030623/26030624

content-type: audio/mpeg

Eben Freeman 0 Reputation points

2025-02-22T23:21:28.63+00:00

Files are protected with sas token, if support is available to research I will provide full urls. The issue is not with the media player, pasting the mp3 urls in chrome demonstrates the behavior. Direct blob download works, CDN fails.
Eben Freeman 0 Reputation points

2025-02-22T23:24:12.6366667+00:00

Comments seem to be failing here, trying again...

Media player is not the issue. Pasting the blob & cdn urls in chrome show the issue - blob works, CDN fails. Files are protected with sas token, I can provide examples if support is available.
Sai Prasanna Sinde 4,170 Reputation points Microsoft External Staff

2025-02-24T05:48:07.2933333+00:00
Hi @Eben Freeman

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

If the origin returns a 206 in response to a range request it must send a proper Content-Range header. The Content-Range header that the origin is sending now is mis-matched/incorrect. You can attempt to resolve the issue by applying one of the following mitigations:

You can disable caching through your azure portal.

If the compression is enabled on both backend and Azure CDN, you can disable compression on their origins(backend) and enable compression on CDN side through your portal. CDN will dynamically compress the content before returning it.

You can also add a RulesEngine rule to Delete "Accept-Encoding" request header or override the "Accept-Encoding" header with "identity" through your azure portal.

Here's a sample rule that will overwrite the Accept-Encoding request header in CDN (other SKUs would be similar):

Kindly let us know if the above helps or you need further assistance on this issue.
Eben Freeman 0 Reputation points

2025-02-24T15:38:47.3533333+00:00

Are you saying Azure blob storage is sending the wrong headers? Direct blob storage request works fine, the CDN fails, for the same file. Both send the same headers as stated earlier.

Azure blob storage works:
<redacted>

Azure CDN fails, audio stops at 8:05:
<redacted>

Where would I find compression settings in Azure blob & CDN?

Can you explain - override the "Accept-Encoding" header with "identity" ?

Please explain how caching can be disabled for specific (.mp3) files that are having the problem. It wouldn't make sense to disable caching for all files since others work fine (images & .mp4).

Other sources suggested removing the Range request header - but Azure CDN doesn't allow that header to be removed.
Eben Freeman 0 Reputation points

2025-02-24T15:41:38.6133333+00:00

test post
Venkat V 550 Reputation points Microsoft External Staff

2025-02-24T17:44:47.6133333+00:00

Hi @Eben Freeman

Welcome to the Microsoft Q&A Platform.

Thank you for reaching out & I hope you are doing well. As you mentioned, Azure CDN stops at 8:05, but for me, it plays continuously without any buffering.

<redacted>

Where would I find compression settings in Azure blob & CDN?

Azure CDN Compression Settings: Navigate to CDN Profile > Endpoints > Select your endpoint > Compression Settings > Ensure compression is enabled (this allows CDN to dynamically compress files rather than relying on the origin).

Bypass caching for .mp3 files and then purge the CDN cache for only .MP3 files

The rule will ensure that all .mp3 files are no longer cached by Azure CDN**. It means that every request for a .mp3 file will go directly to the blob storage instead of being served from the CDN cache.

Reference: https://learn.microsoft.com/en-us/azure/cdn/cdn-purge-endpoint
Venkat V 550 Reputation points Microsoft External Staff

2025-02-25T08:46:50.9033333+00:00

Hi @Eben Freeman

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

2025-02-25T15:19:10.2533333+00:00

I have reviewed but not implemented yet. Currently our app is detecting if the reference is to an mp3 and serving the direct blob storage url instead of the cdn url. Is there any benefit to staying with the cdn url but setting it to bypass the cache for mp3s?

Also, why would the cdn url stop consistently for many users, but for your test it did not - is this an issue with the cdn edge servers maybe some have the full file and some do not? How to fix that?
Eben Freeman 0 Reputation points

2025-02-25T15:23:28.7933333+00:00

test comment - adding an extra comment seems the only way to refresh the full thread. Page refresh does not show the full thread
Venkat V 550 Reputation points Microsoft External Staff

2025-02-25T17:17:18.6266667+00:00

Hi @Eben Freeman

Is there any benefit to staying with the cdn url but setting it to bypass the cache for mp3s?

There are benefits to keeping the Azure CDN URL even if caching is disabled for .mp3 files. However, whether it’s the best choice depends on your specific needs, such as performance, scalability, and security.

If you are facing a buffering issue, you should definitely bypass the rule. This will ensure that all .mp3 files are no longer cached by Azure CDN. It means that every request for a .mp3 file will go directly to the blob storage instead of being served from the CDN cache.

Why Would the Azure CDN URL Stop for Many Users, But Not for Others?

Yes, this is most likely an issue with Azure CDN edge servers (POP locations).

To resolve the issue Purge the CDN Cache for .mp3 Files, This forces ALL CDN edge servers to fetch a fresh copy from Azure Blob Storage.

I hope this helps to resolve your query.

If the above is unclear and/or you are unsure about something, add a comment below.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Eben Freeman 0 Reputation points

2025-02-26T01:35:28.4333333+00:00

I am keeping the CDN for other files but I mean specifically for mp3s, is it still better to go through the CDN (with bypass cache) or direct to the blob storage url? Does it matter?

Having to manually purge the CDN is not a good solution, it doesn't scale and it would be only after the users start complaining about the audio stopping. Is there any way to fix the CDN so that mp3s are always fully cached?
ChaitanyaNaykodi-MSFT 27,041 Reputation points Microsoft Employee

2025-02-27T04:15:30.4566667+00:00

@Eben Freeman

Thank you for reaching out.

I am keeping the CDN for other files but I mean specifically for mp3s, is it still better to go through the CDN (with bypass cache) or direct to the blob storage url? Does it matter?

Ideally it will be better to go through CDN as it will reduce latency for the consumers. If your consumer's experience is not hampered then this should be fine. Azure CDN can just act as a proxy and you can use redirects to Azure Blob Storage for this particular file. Although you can go through this article to validate if your implementation adheres to the best practices for Azure Blob Storage.

A quick plug-in here "Azure CDN Standard from Microsoft (classic) will be retired on September 30, 2027. To avoid any service disruption, it's important that you migrate your Azure CDN Standard from Microsoft (classic) profiles to Azure Front Door Standard or Premium tier by September 30, 2027. For more information, see Azure CDN Standard from Microsoft (classic) retirement."

Azure Front Door offers more features like Web Application Firewall which provides additional security features.

Having to manually purge the CDN is not a good solution, it doesn't scale and it would be only after the users start complaining about the audio stopping. Is there any way to fix the CDN so that mp3s are always fully cached?

Azure CDN provide a functionality to Purge individual asset by specifying the full URL, this is currently documented here.

Purging the file from the Azure CDN cache can force it to retrieve the file again and store it in the cache. I will recommend you to try this in the dev environment first to avoid any service disruptions.

Meanwhile in the Dev environment as suggested in one of the comment above you can try to disabling the cache for this file and see if there are any issues. This will determine if caching is the cause here or not.
Refer: https://learn.microsoft.com/en-us/previous-versions/azure/cdn/cdn-query-string

Thank you!
Eben Freeman 0 Reputation points

2025-02-27T15:23:40.3133333+00:00

Not sure what you are talking about here. There is a problem with the CDN not caching the full file, that's it, please stay on point. The CDN is already Azure Front Door Standard and blob storage is already configured for best practice, access only through SAS tokens. The CDN does not have a problem serving images or mp4 range requests, its only the full mp3 file where the CDN has the problem. Purging does not help, as the file continues to have the problem at least for certain CDN servers even after purge. CDN is definitely the problem, because direct blob storage access has no problem.
ChaitanyaNaykodi-MSFT 27,041 Reputation points Microsoft Employee

2025-02-27T16:25:44.8366667+00:00

@Eben Freeman

Thank you for getting back and confirming it is a Front Door service.

Can you check the Access logs for AFD endpoint and see if you observed any errors? Access logs also provides details around edge server which served the request, it will help us determine if the cause is associated with one edge server or not.

Meanwhile I am making a private message here for some additional details. Thanks!

Share via

Azure CDN not serving full mp3; Direct blob storage works fine

Your answer