CODEWITHSUNDEEP
asp.net-coreazure-front-doorhttp-compression
Technicolour
Technicolour

Reputation: 697

Azure Front Door Content Encoding with disabled caching doesn't pass through from origin server

I am setting up an instance of Azure Front Door (AFD) for a public-facing website to help improve its global page speed performance.

For the root documents/HTML I don't have caching enabled (at the moment still working through appropriate cache controls, but as the site currently sets no-cache, no-store, it wouldn't be worth it) and I have noted that it is now missing a Content-Encoding header and as such is being called on lighthouse scoring.

The origin server is hosted in IIS and is running an aspnetcore application. When requesting from the origin server directly I get brotli response back as expected.

I've read and think I've covered the troubleshooting described here: https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/troubleshoot-compression

I have set up my web.config as so:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <location path="." inheritInChildApplications="false">
        <system.webServer>
            <handlers>
                <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
            </handlers>
            <aspNetCore processPath="dotnet" arguments=".\PublicWebsite.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess">
                <handlerSettings>
                    <handlerSetting name="enableShadowCopy" value="true" />
                    <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
                </handlerSettings>
            </aspNetCore>
        </system.webServer>
    </location>
    <system.webServer>
        <httpCompression noCompressionForHttp10="false" noCompressionForProxies="false" />
    </system.webServer>
</configuration>

The HTML document is 10kb so is above any potential 1kb limit for compression (however I would hope that this isn't in play as the caching configuration is disabled).

My expectation is that end users get a brotli encoded response but currently it seems to just be raw and uncompressed.

Edit: this may just be a limitation of AFD?

https://feedback.azure.com/d365community/idea/b63fd21c-217e-ee11-a81c-000d3ae5ae95 https://feedback.azure.com/d365community/idea/1e3f6e1c-8726-ec11-b6e6-000d3a4f0789

However, that seems bizarre particularly if it's been so long waiting for even just basic passthrough encoding.

Upvotes: 0

Views: 294

Answers (1)

Arko
Arko

Reputation: 3781

You are correct. Azure Front Door does support content encoding even when caching is disabled. It's a limitation that can be addressed with MS- Reference

It's also worth noting that classic Azure Front Door can dynamically compress content on the edge, resulting in a smaller and faster response time to clients. However, if the origin uses Chunked Transfer Encoding to send data to the Front Door POP, then compression isn't supported. Additionally, range requests may be compressed into different sizes, which can cause issues with the Front Door.

References:

feel free to add any additional points from your end for future reference for someone facing similar blocker in Stack overflow community

Upvotes: 0

Related Questions