Windows lets you know when your computer’s Internet connection is limited or absent entirely. What is this sorcery?
Windows attempts to download a file from a dedicated Web server. Depending on which version of Windows, it’s http://www.msftncsi.com/ or http://www.msftconnecttest.com/. If the download is successful and contains the correct contents, then Windows concludes that you have full Internet access.
If something goes wrong, Windows will report either limited or no Internet access, depending on what exactly went wrong.
Ok, now I'm more curious. Why two URLs split on Windows Version, why does not just using a single URL work for all versions?
Also, these files must get a lot of traffic. I believe the connecttest.txt url is using Azure Front Door caching given that it has the x-msedge-ref headers (a callback to when we were called the Edge team for serving Bing traffic before we eventually grew to serve more of Microsoft and eventually...
They changed the URL from “msftncsi” to “msftconnecttest”. One of them makes its purpose obvious, the other is an obscure acronym. They probably did this to make it easier for people looking at their traffic to understand what this thing is.
Also, do you really need a CDN to serve a 14-byte text file, even to millions of people?
I wonder if it’s in the windows source code. I’ll have to find it.
A CDN has many advantages but one example is to give the smallest amount of latency to the client. The CDN has hundreds (thousands?) of "edge" servers all around the world with a copy of the file. If the "origin" server is in the middle of the U.S., and there's no CDN, a client connecting from India would have to travel halfway across the globe and back. With a CDN, the client in India would...
Linux distros do something similar… e.g. on a current Fedora version, it’s http://fedoraproject.org/static/hotspot.txt.
Note that as with the Windows version, the protocol is HTTP, not HTTPS – because captive portals completely break TLS, but plaintext HTTP will result in a clean redirect to the portal, allowing the network service to detect the presence of the portal and to bring up a browser window to let the user authenticate.
And as a tiny PSA: There is http://neverssl.com when you’re in a situation where your device for whatever reason can’t detect the captive portal and you need a plain text site with a relatively easy name to remember.
Similarly, Android and ChromeOS devices expect a HTTP 204 response from http://connectivitycheck.gstatic.com/generate_204 (also HTTP, for the same reason).
It’s possibly the only time I’ve seen a HTTP 204 in the real world 🙂
I use neverssl.com for wifi testing. Since finding a non ssl website becomes harder over time.
I’ve seen HTTP 204 in the real world a few times, REST APIs sometimes return it in response to a DELETE.
Isn’t this heuristic really easy to spoof?
So what if somebody spoofs it? Congratulations, you tricked Windows into showing a “full internet access” icon, and then when the user tries to go to a web site, they get an error. All you’re doing is adding more support costs to deal with customers complaining “Your internet is broken.”