We are using Azure Front Door to serve our white-labeled static website, which means we need our customers to be able to access it through unique subdomains (e.g., cust1.domain.com and cust2.domain.com).
We CNAME *.domain.com to our Front Door instance via DNS, map a route for *.domain.com and have bound it to a custom *.domain.com wildcard certificate (not managed, which is unsupported). The route is pointing to an origin group that in turn points to a "Storage (Static website)" origin similar to prod-storage.z14.web.core.windows.net.
Occasionally on Safari, we receive a response that looks like:
<h2>Our services aren't available right now</h2><p>We're working to restore all services as soon as possible. Please check back soon.</p>0a1LIYwAAAADIYjiE3LgzTLfw86bqHEd5Q0hHRURHRTE2MTAAYTk0OGVmNjEtMTk3NS00ZjA0LTkwMjgtOTgwY2I4YzllYzFl
When reviewing the network tab, we're seeing that response is actually a 421 Misdirected Request. My assumption is that it has to do with this update: https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq#how-does-front-door-handle--domain-fronting--behavior--
What is the correct way to set up this flow to avoid this new issue from Front Door? Our case is somewhat unique and not documented as far as I can tell.
I have seen solutions that include turning off HTTP/2, creating a separate cert per domain and using different IPs - none of which are effective nor will scale with our solution because we need to create new subdomains on the fly with no limitations (i.e., it's not realistic to programmatically add them to AFD).
CodePudding user response：
I ended up solving this by contacting Microsoft support and asking them to turn off the domain fronting block, which appears to have completely resolved the issue on Safari based on our follow up testing. Was hoping for a better solution but this works for us for now.
CodePudding user response：
Interesting that AFD is a reverse proxy, and RFC 7540 9.1.2. states proxies should NOT be generating this response. MS as of November banned domain fronting and supposedly had given warning as of I think April last year to get users to move away from it.
From other research it looks like the reason why Safari doesn't handle this correctly is that the same RFC section referenced above says the client "MAY try the request -- whether the request method is idempotent or not -- over a different connection." Safari doesn't appear to retry this TLS connection with correct SNI, whereas other browsers will.
What I'm curious about though is how this looks in a trace. For your other browsers that are working, do the Dev Tools show this 421 being returned followed by an immediate attempt to retrieve the resource again?