Closed
Bug 1112330
Opened 10 years ago
Closed 8 years ago
Setup domain for captive portal detection
Categories
(Cloud Services :: Web Site - Deprecated, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: valentin, Unassigned)
References
Details
Bug 1048131 is currently tracking the implementation of a captive detection service for Firefox Desktop, that would provide reliable signals on whether the user has internet connectivity.
We require a page similar to http://detectportal.firefox.com/, but maybe hosted on a mozilla.org domain, that would scale for hundreds of millions of users.
In the meeting we discussed whether the addons.mozilla.org would be appropriate, considering that we already use it. However, it seems that it probably can't handle the load, and also traffic to it is logged for metrics purposes.
I think that something similar to detectportal.services.mozilla.com, or even detectportal.addons.mozilla.org would be acceptable for this task, provided that there's no logging of requests (it would be pointless anyway), and that the system will scale.
Reporter | ||
Comment 1•10 years ago
|
||
Patrick, any thoughts on the domain and requirements?
Flags: needinfo?(mcmanus)
Comment 2•10 years ago
|
||
so I think anything in mozilla.org meets the requirement that someone who controls that delegation already gets a daily trackable (though we don't!) query..
I would just gate the portal detection code on whether or not the addons check is disabled or not. (I assume that's preffable?)
Flags: needinfo?(mcmanus)
Reporter | ||
Comment 3•9 years ago
|
||
Hi Benson,
We are starting work on a captive portal UI. That means that as soon as the UI lands in Nightly, we might be getting millions of requests per day to our captive portal page. After it hits release, we are looking at more than a billion requests per day.
We need to be sure that our end point can handle all these requests, and that no logging of requests occurs on the server.
Also, as Patrick mentioned in comment 2, something under mozilla.org would be preferable.
Flags: needinfo?(bwong)
Comment 4•9 years ago
|
||
- we can make subdomains under: mozilla.org, mozilla.com, services.mozilla.com or firefox.com
- how are you calculating millions/billions of requests/day?
- is it static or dynamic content?
Flags: needinfo?(bwong)
Reporter | ||
Comment 5•9 years ago
|
||
(In reply to Benson Wong [:mostlygeek] from comment #4)
> - we can make subdomains under: mozilla.org, mozilla.com,
> services.mozilla.com or firefox.com
It's up to Patrick which domain we want.
> - how are you calculating millions/billions of requests/day?
For release, a conservative estimate of 200 mil users x 5 requests/day = 1 billion req/day
> - is it static or dynamic content?
Static, of a very small size. The response should only contain "success\n".
Comment 6•9 years ago
|
||
(In reply to Valentin Gosu [:valentin] from comment #5)
> It's up to Patrick which domain we want.
>
maybe ask bsmedberg to get it aligned with any other automatic activity.
Reporter | ||
Comment 7•9 years ago
|
||
(In reply to Patrick McManus [:mcmanus] from comment #6)
> > It's up to Patrick which domain we want.
> maybe ask bsmedberg to get it aligned with any other automatic activity.
Hi Benjamin,
Do you have some input on what subdomain would be most appropriate for the captive portal endpoint? According to comment 4, we have a number of possibilities.
Flags: needinfo?(benjamin)
Comment 8•9 years ago
|
||
Typically we use *.mozilla.org endpoints so that's what I would recommend, all else being equal. I don't think it matters from a data/privacy perspective.
Flags: needinfo?(benjamin)
Comment 9•8 years ago
|
||
This is live at http://detectportal.mozilla.org. It's managed by Cloudops. Closing this old bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 10•8 years ago
|
||
(In reply to Benson Wong [:mostlygeek] from comment #9)
> This is live at http://detectportal.mozilla.org. It's managed by Cloudops.
> Closing this old bug.
I think the domain is still http://detectportal.firefox.com - right?
Comment 11•8 years ago
|
||
yes. Sorry my mistake.
You need to log in
before you can comment on or make changes to this bug.
Description
•