Critical: Azure Front Door HTTP/2 Protocol Errors Causing Static Asset Load Failures

Question

Critical: Azure Front Door HTTP/2 Protocol Errors Causing Static Asset Load Failures

Mark Blackburn 40

Problem Summary

We are experiencing consistent HTTP/2 protocol failures when serving static assets (CSS/JS) through Azure Front Door on the domain:

https://www.ballarat.viccountrymasters.com/

The same assets load correctly when accessed directly via the App Service origin:

https://vcmasters.azurewebsites.net

The failures occur only when using Azure Front Door + HTTP/2, affecting all browsers and multiple devices, including mobile.

This results in broken pages, missing styles, missing scripts, and incomplete rendering.

Impact

Website becomes unusable for users served via this Front Door endpoint.

Occurs across PCs, mobile devices, and incognito mode.

Affects production domain traffic.

Issue persists across multiple networks.

Breaking core user experience.

This is production-impacting and requires urgent investigation.

Expected Behavior

Static assets such as /_next/static/css/*.css and /_next/static/chunks/*.js should load normally via Azure Front Door, just as they do when sourced directly from the origin App Service.

Actual Behavior

Through the Front Door domain:

HTML loads successfully.

Static assets begin loading but then stall, hang, or disappear.

Browser Console shows:

net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK)

This error is specific to HTTP/2.

When forced to HTTP/1.1 (via Chrome --disable-http2), the site loads perfectly.

Reproduction Steps

Visit: https://www.ballarat.viccountrymasters.com/

Observe:

Page renders partially.

  CSS/JS files enter “pending” state.
  
     Some eventually disappear from Network list.
     
     Console reports:
     
     ```
     net::ERR_HTTP2_PROTOCOL_ERROR
     ```
     
     Retry using HTTP/1.1:
     
        Launch Chrome with: `chrome.exe --disable-http2 --disable-quic`
        
           Website loads correctly every time.
           
           Direct origin works 100%: `https://vcmasters.azurewebsites.net/?club=ballarat`
           
           Mobile device tests fail the same way over LTE + WiFi.

Routing / Config Verification

No path rewrites affecting /_next/static/* or /images/*.

No origin path set.

Origin host header correctly set to vcmasters.azurewebsites.net.

Rule sets cleanly scoped and functioning.

All Front Door static caching rules are correct.

No WAF interference.

AFD returns proper 200 responses and caches files with TCP_HIT/TCP_MISS as expected.

📌 Detailed Technical Evidence

1. CSS Headers: Origin vs AFD (Identical)

Origin

HTTP/1.1 200 OK
Content-Length: 27632
Content-Type: text/css; charset=UTF-8
Cache-Control: public, max-age=31536000, immutable
ETag: W/"6bf0-19a83fd7810"
Last-Modified: Fri, 14 Nov 2025 20:10:18 GMT

AFD

HTTP/1.1 200 OK
Content-Length: 27632
Content-Type: text/css; charset=UTF-8
Cache-Control: public, max-age=31536000, immutable
ETag: W/"6bf0-19a83fd7810"
Last-Modified: Fri, 14 Nov 2025 20:10:18 GMT
X-Cache: TCP_MISS
X-Static-Asset: true

2. JS Headers: Origin vs AFD (Identical)

Origin

Content-Length: 3557
ETag: W/"de5-19a83fd7810"

AFD

Content-Length: 3557
ETag: W/"de5-19a83fd7810"

3. Full File Hash Comparison (Byte-Identical)

CSS File

SHA256 (origin) = F650E94095AED5C26EFF070280CCE9020919D5804D242EB62711BA085D8A0303
SHA256 (AFD)    = F650E94095AED5C26EFF070280CCE9020919D5804D242EB62711BA085D8A0303

JS File

SHA256 (origin) = 1BDB0DD87714CECD54DB2509FC17767CE17B4606EE0EEC9FACA0871AB8FD87CA
SHA256 (AFD)    = 1BDB0DD87714CECD54DB2509FC17767CE17B4606EE0EEC9FACA0871AB8FD87CA

➡ AFD is serving the correct bytes.

4. Browser Error

Chrome consistently logs:

net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK)

Requests stall mid-stream in HTTP/2. Retrying under HTTP/1.1 makes the problem disappear.

Conclusion

All evidence indicates this is not an application issue, not a config issue, and not a caching issue.

This is almost certainly a Front Door POP HTTP/2 stream corruption or framing problem, affecting delivery of multiplexed static assets.

We request:

🔧 Urgent investigation into the Azure Front Door edge POP(s) serving our traffic, specifically for:

HTTP/2 frame integrity

Stream resets

GOAWAY or RST_STREAM behavior

Any known regressions affecting static asset delivery

We can provide:

HAR files

Additional headers

Timestamps

Client IP ranges for correlation

Please advise next steps or mitigation.

Problem Summary

We are experiencing consistent HTTP/2 protocol failures when serving static assets (CSS/JS) through Azure Front Door on the domain:

https:

The same assets load correctly when accessed directly via the App Service origin:

https:

The failures occur only when using Azure Front Door + HTTP/2, affecting all browsers and multiple devices, including mobile.

This results in broken pages, missing styles, missing scripts, and incomplete rendering.

Impact

Website becomes unusable for users served via this Front Door endpoint.

Occurs across PCs, mobile devices, and incognito mode.

Affects production domain traffic.

Issue persists across multiple networks.

Breaking core user experience.

This is production-impacting and requires urgent investigation.

Expected Behavior

Static assets such as /_next/static/css/*.css and /_next/static/chunks/*.js should load normally via Azure Front Door, just as they do when sourced directly from the origin App Service.

Actual Behavior

Through the Front Door domain:

HTML loads successfully.

Static assets begin loading but then stall, hang, or disappear.

Browser Console shows:

net::ERR_HTTP2_PROTOCOL_ERROR

This error is specific to HTTP/2.

When forced to HTTP/1.1 (via Chrome --disable-http2), the site loads perfectly.

Reproduction Steps

Visit:
https://www.ballarat.viccountrymasters.com/

Observe:

Page renders partially.

  CSS/JS files enter “pending” state.
  
     Some eventually disappear from Network list.
     
     Console reports:
     
     ```
     net::ERR_HTTP2_PROTOCOL_ERROR
     ```
     
     Retry using HTTP/1.1:
     
        Launch Chrome with:  
         `chrome.exe --disable-http2 --disable-quic`
        
           Website loads correctly every time.
           
           Direct origin works 100%:  
            `https://vcmasters.azurewebsites.net/?club=ballarat`
           
           Mobile device tests fail the same way over LTE + WiFi.

Routing / Config Verification

No path rewrites affecting /_next/static/* or /images/*.

No origin path set.

Origin host header correctly set to vcmasters.azurewebsites.net.

Rule sets cleanly scoped and functioning.

All Front Door static caching rules are correct.

No WAF interference.

AFD returns proper 200 responses and caches files with TCP_HIT/TCP_MISS as expected.

📌 Detailed Technical Evidence

1. CSS Headers: Origin vs AFD (Identical)

Origin

HTTP/1.1

AFD

HTTP/1.1

2. JS Headers: Origin vs AFD (Identical)

Origin

Content-Length

AFD

Content-Length

3. Full File Hash Comparison (Byte-Identical)

CSS File

SHA256 (origin) =

JS File

SHA256 (origin) =

➡ AFD is serving the correct bytes.

4. Browser Error

Chrome consistently logs:

net::ERR_HTTP2_PROTOCOL_ERROR

Requests stall mid-stream in HTTP/2.
Retrying under HTTP/1.1 makes the problem disappear.

Conclusion

All evidence indicates this is not an application issue, not a config issue, and not a caching issue.

This is almost certainly a Front Door POP HTTP/2 stream corruption or framing problem, affecting delivery of multiplexed static assets.

We request:

🔧 Urgent investigation into the Azure Front Door edge POP(s) serving our traffic, specifically for:

HTTP/2 frame integrity

Stream resets

GOAWAY or RST_STREAM behavior

Any known regressions affecting static asset delivery

We can provide:

HAR files

Additional headers

Timestamps

Client IP ranges for correlation

Please advise next steps or mitigation.

Ravi Varma Mudduluru 11,955 Reputation points Microsoft External Staff Moderator

2025-11-14T13:26:33.18+00:00

Hello @Mark Blackburn,

Thanks for reaching out to Microsoft Q&A.

We are currently working on this issue, will provide you an update soon.
Vallepu Venkateswarlu 9,830 Reputation points Microsoft External Staff Moderator

2025-11-14T14:11:15.2633333+00:00

Hi @Mark Blackburn

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

Could you please confirm whether compression is enabled on your application side?

If your application is applying compression, please try disabling it temporarily and test the result. Azure Front Door already provides compression, and enabling compression both on the application and Front Door can cause issues with HTTP/2 delivery.

Please check the affected URLs using cURL to verify the responses and share the cURL response in a private message so we can investigate further.

Please refer to the thread below for additional details on identifying the root cause of the issue.

https://learn.microsoft.com/en-us/answers/questions/1338000/http2-protocol-error-with-azure-cdn

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Mark Blackburn 40 Reputation points

2025-11-15T05:34:49.2933333+00:00
Hello team,

Thanks for your guidance. We’ve confirmed that the issue was caused by application-side compression combined with Azure Front Door compression, which led to HTTP/2 protocol errors on static asset delivery.

To resolve this, we applied the following changes:

Disabled compression in Next.js Added compress: false to next.config.js.

Disabled App Service content compression Added the App Setting:

WEBSITES_DISABLE_CONTENT_COMPRESSION = 1

After redeploying with these changes, the site now works correctly under HTTP/2, and all previous issues (ERR_HTTP2_PROTOCOL_ERROR, stalled static assets, disappearing JS/CSS requests) are fully resolved.

Thank you for the assistance—this has addressed the problem.

Answer accepted by question author

0 additional answers

Your answer

Ravi Varma Mudduluru 11,955 Reputation points Microsoft External Staff Moderator

2025-11-14T13:26:33.18+00:00

Hello @Mark Blackburn,

Thanks for reaching out to Microsoft Q&A.

We are currently working on this issue, will provide you an update soon.
Vallepu Venkateswarlu 9,830 Reputation points Microsoft External Staff Moderator

2025-11-14T14:11:15.2633333+00:00

Hi @Mark Blackburn

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

Could you please confirm whether compression is enabled on your application side?

If your application is applying compression, please try disabling it temporarily and test the result. Azure Front Door already provides compression, and enabling compression both on the application and Front Door can cause issues with HTTP/2 delivery.

Please check the affected URLs using cURL to verify the responses and share the cURL response in a private message so we can investigate further.

Please refer to the thread below for additional details on identifying the root cause of the issue.

https://learn.microsoft.com/en-us/answers/questions/1338000/http2-protocol-error-with-azure-cdn

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Mark Blackburn 40 Reputation points

2025-11-15T05:34:49.2933333+00:00

Hello team,

Thanks for your guidance. We’ve confirmed that the issue was caused by application-side compression combined with Azure Front Door compression, which led to HTTP/2 protocol errors on static asset delivery.

To resolve this, we applied the following changes:

Disabled compression in Next.js Added compress: false to next.config.js.

Disabled App Service content compression Added the App Setting:

WEBSITES_DISABLE_CONTENT_COMPRESSION = 1

After redeploying with these changes, the site now works correctly under HTTP/2, and all previous issues (ERR_HTTP2_PROTOCOL_ERROR, stalled static assets, disappearing JS/CSS requests) are fully resolved.

Thank you for the assistance—this has addressed the problem.

Answer 1

Hi @Mark Blackburn

Thank you for your reply, and I’m glad to hear that the issue has now been resolved.

As you confirmed, the problem was caused by application-side compression being enabled along with Azure Front Door compression. When both are active, it can lead to HTTP/2 protocol errors during static asset delivery (CSS/JS), resulting in stalled requests, partial page rendering, and ERR_HTTP2_PROTOCOL_ERROR.

As I can see, the issue has been resolved by following the guidance shared earlier regarding disabling compression at the application level.

Disabling compression in Next.js Added the setting in next.config.js:
```
  compress: false
```
Disabling App Service content compression Added the App Setting.
```
  WEBSITES_DISABLE_CONTENT_COMPRESSION = 1
```

After applying these configurations and redeploying, the site is now loading correctly over HTTP/2. All previous issues, including stalled static assets and disappearing CSS/JS files are fully loaded correctly.

Please refer to the thread below for additional details on identifying the root cause of the issue.

https://learn.microsoft.com/en-us/answers/questions/1338000/http2-protocol-error-with-azure-cdn

Glad to know everything is working as expected now. Let us know if you need any further assistance.

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

Share via

Critical: Azure Front Door HTTP/2 Protocol Errors Causing Static Asset Load Failures

Problem Summary

Impact

Expected Behavior

Actual Behavior

Reproduction Steps

Routing / Config Verification

📌 Detailed Technical Evidence

1. CSS Headers: Origin vs AFD (Identical)

2. JS Headers: Origin vs AFD (Identical)

3. Full File Hash Comparison (Byte-Identical)

4. Browser Error

Conclusion

🔧 Urgent investigation into the Azure Front Door edge POP(s) serving our traffic, specifically for:

Problem Summary

Impact

Expected Behavior

Actual Behavior

Reproduction Steps

Routing / Config Verification

📌 Detailed Technical Evidence

1. CSS Headers: Origin vs AFD (Identical)

2. JS Headers: Origin vs AFD (Identical)

3. Full File Hash Comparison (Byte-Identical)

4. Browser Error

Conclusion

🔧 Urgent investigation into the Azure Front Door edge POP(s) serving our traffic, specifically for:

0 additional answers

Your answer