Front Door and CDN with blob storage compression doesn't work

Neil Pendlington 0

I set up a storage account (StorageV2 (general purpose v2)). A container with access level of anonymous read for blobs only, I can then use a web browser to hit the blob endpoint and get it returned in raw form.

Response Headers:
User's image

Setting up a new Front Door and CDN profile, I configure the route to enable compression:
User's image

And the origin settings point to the blob endpoint which has the MIME type "text/plain" in the allow list.

When I access the CDN endpoint (front door) via the browser, then the response is never compressed. Despite the request having an Accept Encoding header with "gzip, deflate, br, zstd", the response headers never include a Content Encoding header to indicate a compressed stream. And most confusingly, the response headers do include a Transfer Encoding chunked value.

I spent a while diagnosing blob storage returning chunked responses, until I realised that this must be something the Front Door CDN is doing as directly accessing the blob, there is no CTE happening.

I've used https://zcusa.951200.xyz/en-us/azure/frontdoor/standard-premium/troubleshoot-compression to try and diagnose, but as far as I can see, none of the conditions for the compression failing are met.

As an aside, I managed to get it working perfectly using Azure CDN, however with this being deprecated in 2027, I was hoping to have it working in Front Door so I don't need to worry about migration later on or problems like this biting me!

Have I just missed a configuration option, or is this a bug?

KapilAnanth-MSFT 48,081 Reputation points Microsoft Employee

2024-12-24T11:44:20.3966667+00:00
@Neil Pendlington ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

Can you please confirm if file size is not above 8 MB ?

If this is your first time setting up compression, wait 1-2 hours to ensure settings have propagated to the POPs

Did you try to access the files from a different region? (different POPs)

Cheers,

Kapil
Neil Pendlington 0 Reputation points

2024-12-24T12:07:42.4666667+00:00

Thanks for the response. Yes, I verified the other criteria on the learn page I linked to that could have accounted for it.
The file size is ~53Kb as can be seen from the screenshot and the Content Length header, so well in the range that's supported.
I created the resource last night, and after some debugging on the issue, I went to bed so I effectively waited for around 10 hours and the result was the same.

I also tried to purge the cache as part of the experimentation so I don't think that the built-in caching was causing the problem.
GitaraniSharma-MSFT 49,671 Reputation points Microsoft Employee

2024-12-26T15:50:17.36+00:00
Hello @Neil Pendlington ,

Thank you for the update.

So, till now we have validated the below:

Compression is enabled on Azure Front Door.

MIME type "text/plain" is added in the allow list.

The file size is more than 1 KB and less than 8 MB.

And you believe, CTE (Chunked Transfer Encoding) is not happening.

I would like to gather the below details for further troubleshooting of this issue:

Could you please make sure that the MIME type "text/plain" is available in the default list of MIME types on Azure Front Door Optimizations page?

Could you please confirm if you are getting a HTTP 200 response on accessing the content or any other responses such as intermittent 503 etc?

Do you have any other resource in between the blob storage and Azure Front Door?

Have you added any rules in the Azure Front Door rules engine for any purpose?

Regards,

Gita Sharma
Neil Pendlington 0 Reputation points

2024-12-27T12:46:38.5633333+00:00
I've not modified the available MIME types from the default, which includes "text/plain", so that's definitely set. I also tried with a file with the .js extension which is correctly served by the blob storage as "text/javascript" but got the same result.

Yes, accessing content, I am getting a 200 response from the front door endpoint.

Nothing else is between the two systems that could interact or interfere with the traffic.

I have no other rules - the front door was created explicitly for the serving of the blob storage via CDN.
GitaraniSharma-MSFT 49,671 Reputation points Microsoft Employee

2024-12-27T13:52:39.6866667+00:00

@Neil Pendlington , thank you for the details.

Based on our discussion and the details provided, the most likely cause of this issue appears to be the point you mentioned in your initial query: "the response headers do include a Transfer Encoding chunked value".

As documented in the Azure Front Door Compression Rules,

If the origin uses Chunked Transfer Encoding (CTE) to send data to the Azure Front Door POP, then compression isn't supported.

However, you also mentioned that you’ve already diagnosed your Blob Storage and confirmed that Chunked Transfer Encoding (CTE) is not occurring.

That said, I’d like to explore this point further, if possible. Could you please share your Front Door URL via the private message so I can review it further?

Regards,

Gita

Share via

Front Door and CDN with blob storage compression doesn't work

Your answer