In the event that Chrome detects SSL connection timeouts, certificate errors, or other network issues that might be caused by a captive portal (a hotel’s WiFi network, for instance), Chrome will make a cookieless request to http://www.gstatic.com/generate_204 and check the response code. If that request is redirected, Chrome will open the redirect target in a new tab on the assumption that it’s a login page. Requests to the captive portal detection page are not logged.
I discovered this is how Android devices generally detect captive portals on free wifi networks.
MacOS does something similar right inside the WiFi stack and pops up a web view modal for the portal login if detected (specifically, /System/Library/CoreServices/Captive Network Assistant.app).
Great idea—I’ve always just used my personal website for this, now I have one more reason to SSL it :)
This seems very similar to the generate_204 page from Google:
http://clients3.google.com/generate_204http://stackoverflow.com/questions/1989214/google-com-and-clients1-google-com-generate-204
I discovered this is how Android devices generally detect captive portals on free wifi networks.
MacOS does something similar right inside the WiFi stack and pops up a web view modal for the portal login if detected (specifically,
/System/Library/CoreServices/Captive Network Assistant.app).It uses http://captive.apple.com/hotspot-detect.html, or http://www.apple.com/library/test/success.html in 10.9 or older. (No idea why it changed… maybe they want to HSTS the domain eventually?)
Why use this over example.com?
Nice to have a neutral alternative to those pages mentioned in comments.