About 10 minutes later, they seem to have restored the URL, and normal wifi access points are no longer incorrectly detected as captive.
Apple just fell quite a few points for me.
I'd be more interested in learning how iOS reacts when TCP (HTTP) connections to that URL time out, or are treated as a closed port.
I guess if you're a large corporate and you don't want iPads/iPhones using your wifi, this is an absolutely great way to block them with zero effort!
For what it's worth, recent copies of Android try to help you through the captive portal process as well, though I doubt they fail if android/google.com go down. (Though, Android has always had an indicator, they only become colored after Gapps makes a good connection to Google)
Besides the fact that it's terribly fragile (as seen here), but if it's really an anti-imposter measure, it's a pretty awful one. (Okay, we'll just MITM every non-apple.com URL).
A great many wifi networks are open to the public, but redirect all HTTP requests to a login page. Think airports, coffee shops, hotels, etc. This is called a "captive" network. The apple.com request here is a heuristic to detect the "captive" network, so it can show a web browser inline that shows you the redirected URL so you can log in. This is actually a really nice feature when you're on a captive network.
If the page times out, I don't know what happens. But this time, the page explicitly responded with a 404, which it "should never do", so the device successfully detected a "MITM" and did the right thing. (Except in this case, apple.com webmasters screwed up)
When did "successful wifi connection" mean having access to this unstable apple.com url?
Remember Apple never optimises for edge case.
My ISP requires me to login through a browser to give me access. I am sure majority are on always on connection but there might be a good number for this kind of setup too. What about airport token logins? Didn't expected this in an Apple device.
When a main frame HTTPS load is taking a while, we preemptively open a background request for http://www.gstatic.com/generate_204, and check the response code. We do the same when displaying SSL warnings and ERR_SSL_PROTOCOL_ERROR pages. The URL points to a service that returns HTTP 204 (“No Content”) responses, and the domain does not set any cookies or save any logs. If we’re not behind a captive portal, and connected to the Internet, we should get the 204 response code. If we’re behind a captive portal, we should either get the logon page or a redirect to one. If we get an error or a non-HTTP response, we’re either not behind a captive portal, or can’t find the logon page if we are. For the purposes of captive portal discovery, we treat all HTTP status codes except 2xx, 3xx, and 511 as errors. This works regardless of whether the captive portal works by intercepting DNS or HTTP traffic.
We also preemptively run captive portal checks when displaying SSL certificate error pages, since these are often caused by captive portals as well. There is no timeout in this case.
This is the url all iOS devices request as soon as they are connected to wifi. And It is currently down.
Edit: It is back now. And this is the response:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
iOS falls back to 3G when the page doesn't respond as expected.
First Negative Forum Post - Response Time: 06:00 PM (same day) : "I think this is the worst iOS release to date.
And Steve would've never allowed this."
Due of the Internet archive, these forum posts may well be our greatest legacy.
I understand the reasoning, but for it to totally wipe out Wifi?
I just don't understand how it completely destroys wifi when inaccessible. Windows 7 does a similar thing, but when the page is inaccessible, it doesn't completely kill the internet connection.
Basically, if Apples servers dissapear... Am I to believe that wifi becomes a useless feature on my iDevice, or am I missing a piece of the puzzle?
From http://arstechnica.com/apple/2012/08/apple-lifts-curtain-on-... :
> Apple has sold 46.5 million iPod touch units in the US between the device's introduction in 2007 and the second quarter of 2012. (That's in addition to the nearly 86 million iPhones and 34 million iPads sold during that time.)
iPod Touches alone are 28% of total iOS sales. If wifi-only iPads make up 60% of iPad sales (and I think they're probably higher), then that's 40%. Consider also that the turnover rate on phones is probably higher than the more focused devices.
Fortunately the Apple Store replaced it. Free too.
It's a lame way to do it though.