What seems to have happened was that the people managing www.apple.com 404'ed the URL http://www.apple.com/library/test/success.html, which iOS loads automatically upon associating with a wifi AP. This causes iOS to believe the wifi is actually one of those public "captive" hotspots that redirects all HTTP before you authenticate/pay up, and fires up a modal web browser intending to let you log in.
About 10 minutes later, they seem to have restored the URL, and normal wifi access points are no longer incorrectly detected as captive.
What kind of blockage did you set up? A hijacking 404/403 HTTP response, or are you dropping IP packets to the www.apple.com IP addresses? If your router blocking is implemented on the HTTP level, then obviously you would see the same result as everyone just did when that URL returned 404.
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 love a good reason to be upset but I sympathize with this bug. It should be easy to get around the captive portal issue and they should have other contact domains besides apple.com (in fact, that's the most offensive part of this), but it's an admirable task. Imagine if you connect to the Wifi and it didn't do this... you'd have no idea why you're not receiving any of your data.
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)
It's not an inability to access the site, it is explicitly receiving an invalid and unexpected response code, which indicates an impostor is returning responses instead of apple.com. (Except this time, they screwed up).
Exactly. If apple.com goes down, that doesn't look like a captive network. It's only if the site is up and responsive and returning the wrong result (which is what happened today) that incorrectly indicates the captive network.
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.
Right, as I mention in another comment, I'm well aware of this. However, it shouldn't be the end all be all and it should be more redundant anyway. It should use more domains. It should still allow the user to use the Wifi network if they want to. etc.
The devices aren't down, they just fall back to 3G.
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)
No it's still broken (posting three hours after your comment) and fixing the 404 on apple link won't fix it.
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.