This bug is to follow up on the server request for Bug 752982 - Captive portal pop up dialog is not automatically triggered on Wifi connect To support captive portal detection in B2G, there needs to be a captive portal detection server hosted. Not sure if this is the correct component, please change if needed. Thanks
Could we get some more detail into this bug to describe what needs to be implemented? Do we need a new server or just a specific page (and what URL)? What string(s) should the page contain?
(In reply to Lucas Adamski from comment #1) > Could we get some more detail into this bug to describe what needs to be > implemented? Do we need a new server or just a specific page (and what URL)? > What string(s) should the page contain? We only need a static web page like http://people.mozilla.org/~schien/test.txt. The page content could simply use "Success".
Your test page currently returns "true". Should we use that or "Success"? I'm guessing the device expects something specific?
(In reply to Lucas Adamski from comment #3) > Your test page currently returns "true". Should we use that or "Success"? > I'm guessing the device expects something specific? The returned value is configured in the captivedetect.canonicalContent preference, so it can be anything.
Could we get an ETA for this bug please? Its a blocker for 1.0.1 (shira requirement).
Punting to a more appropriate queue.
Just to confirm. This just need to be one text file, containing the work "success" and can be hosted at any URL? Does it need TLS or can it just be plain http?
Sorry this was (unfortunately) covered via email earlier: Yes, I think we should expect this to scale to a very high number of connections. Putting this on some linearly scalable solution would make the most sense. Good question re HTTP vs HTTPS, but I believe it actually should be HTTP. Reasoning is that if a captive portal wants to MITM HTTPS to put in a login, it'll end up throwing an untrusted cert chain error and so we'll have to assume any cert error == captive portal anyway. So it doesn't seem to buy us anything. Adding Paul to sanity check, tho. A page just containing the string "success" makes sense to me.
I don't see a Paul in the CC list.
Clearing NI on me, I think that was covered in previous comment.
Sorry I replied to the email, not the bug. TLDR: use http not https. With http Wifi network could intercept/spoof the expected response, but all that would do is: * provide the expected response (instead of us) -> Captive portal sign-on doesn't load, and this is actually needed sometimes for weird portals * try to poison the cache to DoS this feature -> current code bypasses the cache  so no issue here. So I can't see an issue here with using http. And afaict, with current code, https wouldn't actually work, since we only trigger captive portal on non-matching response OR HTTP redirect. IE we don't trigger on other errors, such as cert errors. Some brief research also seems to point to both IoS and Android doing this detection over http, not https.  https://mxr.mozilla.org/mozilla-central/source/toolkit/components/captivedetect/captivedetect.js#29
BTW, this is how Apple does it. http://erratasec.blogspot.com/2010/09/apples-secret-wispr-request.html
Is my proposal in comment 7 adequate? What can I do to close this out?
(In reply to Jeremy Orem [:oremj] from comment #14) > Is my proposal in comment 7 adequate? What can I do to close this out? Txt file hosted by plain http is enough.
File is hosted at http://detectportal.firefox.com/success.txt. Monitoring will be set up in Bug 866200.