5 ms·
You can use the addresses that Google and Apple products use to detect captive portals. Google uses http://connectivitycheck.gstatic.com/generate_204 http://co
by atdt 10y ago
You can use the addresses that Google and Apple products use to detect captive portals.
Google uses http://connectivitycheck.gstatic.com/generate_204 http://connectivitycheck.gstatic.com/generate_204.
Apple uses http://captive.apple.com/hotspot-detect.html http://captive.apple.com/hotspot-detect.html and http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html.
- chinathrow 10y agoI was pretty sure that my Android Version uses google.com for the 204 generation. Without further updates, that would break.
- icebraining 10y agoProbably not; google.com will still reply on HTTP, it's just that if you have a browser that visits the HTTPS page, it'll record a rule to never visit the HTTP version. I doubt the code doing captive portal detection supports HSTS at all, so most likely it'll still work just fine.
- chinathrow 10y agoBut that would be exactly the use case here; browse google manually and then hsts kicks in from then on. Later, I get a captive portal wifi and it uses http://www.google.com/generate_204 http://www.google.com/generate_204 and whoops, no request sent and no way for the wifi to redirect me to their login portal. Both happens in chrome hence the same browser context.
- icebraining 10y agoAh, right; I was thinking about the detection mechanism (which probably doesn't use Chrome), not the redirection.
- chinathrow 10y agoRight, the detection mechanism is part of the OS, not the browser. https://developer.android.com/reference/android/net/ConnectivityManager.html https://developer.android.com/reference/android/net/Connecti...