My iPhone constantly misses captive portals and I have to hunt for a non-ssl website. I can't say if it's 5% or 30% of networks, but enough to be frustrating. Does anyone know if it is common for apple.com to be whitelisted for iMessage or something?
The captive portal browser (pop-up on macOS, slide-over on iOS) doesn't support full JavaScript or cookies (or previously didn't, maybe that has changed), so some captive portals specifically allow the captive portal test domains through.
I've never seen a setting for it. It's just a modal dialog with a webview. Like iOS, you have "Cancel" as an option until it connects and changes to "Done."
Except some portals actively try to avoid intercepting any of Apple's methods for determining whether you're on one. You're much better off with an off the beaten path solution.
Any site that doesn't redirect to the SSL version (if applicable) will work. The benefit of using something like captive.apple.com is that it's specifically designed to NOT use SSL in order to trigger redirects and such, whereas something like example.com just so happens to not redirect to their SSL version, so it's (essentially) guaranteed to work vs example.com who could decide in the future to redirect to their SSL version if they want
If I regularly used that as a known-good site that should be up with no SSL, I'd trust that an apple-maintained site (backed by akamai) would be up before "example.com".
I'm sure there are plenty of others, but someone might remember that URL over another so I thought it would be helpful.
It's reserved for the purpose of documentation/illustrations (especially RFCs themselves) without fear of changes/invalid domains/directing mass traffic. It's also useful for establishing an idiom for those RFC examples.
example.com is maintained by IANA. It's an official example address for documentation purposes. So on one hand, it will survive even if Apple disappears, on the other, they're likely not expecting any significant traffic.
Using the site for captive portal access does not actually generate any traffic for the site, because the middlebox intercepts and rewrites the request. Traffic only occurs if there is no captive portal. Hence the easily parsed "Success" body of the Apple site.
Phones confirm whether you passed the captive portal by requesting the usual check url again. That means they'll still get one request after a successful login.
