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

Question

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

Eben Freeman 20

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 20 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 20 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 6,645 Reputation points Microsoft External Staff Moderator

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 20 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 20 Reputation points

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

test post
Venkat V 2,545 Reputation points Microsoft External Staff Moderator

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

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

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 20 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,476 Reputation points Microsoft Employee Moderator

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 20 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.

Accepted answer

1 additional answer

Your answer

Eben Freeman 20 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 20 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 6,645 Reputation points Microsoft External Staff Moderator

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 20 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 20 Reputation points

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

test post
Venkat V 2,545 Reputation points Microsoft External Staff Moderator

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

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

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 20 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?
Eben Freeman 20 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.

Answer 1

@Eben Freeman

Thank you for your patience here, I am just summarizing our discussion here for community benefit.

Issue Description:

You experienced an issue where Azure Front Door was not serving a full MP3 file to the browser. As a result, the media player (video.js) stopped and spun after a few minutes. This problem occurred daily and did not happen six months ago. However, direct blob storage worked fine.

Solution:

While we were troubleshooting this issue, the work around followed here was to serve the file directly from the Blob Storage using redirect.

Meanwhile during our screenshare session we were able to reproduce the issue, as the audio file was played the first chunk of data was received from AFD and the next chunk of the data was never received and the audio player remained in stuck state. We did some additional troubleshooting using the Reference strings provided and were able to link this to a known issue affecting AFD.

The backend team was able to fix this issue and the fix has been deployed in prod. As per recent communication after the fix the audio file was playable in full.

Please let me know if you have any questions. Thank you!

Please click "Accept" the answer as original posters help the community find answers faster by identifying the correct answer.

Answer 2

Deleted

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

Comments have been turned off. Learn more

Share via

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

1 additional answer

Your answer