[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] Starting to discuss Captive Portals
We should specify behavior of both the CP and the client. Specifically,
the client MUST display the CP's web page. And hope that most people
obey the rules, otherwise we will get into another race between OS
vendors and CP vendors.
On 30 March 2015 at 15:14, Warren Kumari <[email protected]> wrote:
I suspect that we are going to be spending a significant amount of our
time with the tension between making the user's life better, and also
trying to maximize the CP operator's desires.
Obviously, because the technical concerns aren't what is hard here.
And this is my fantasy solution:
/.well-known/captive/status - returns a basic status (CP open/closed),
and optionally, an expiration time for this information, i.e. when you
need to poll the status again.
/.well-known/captive/refresh - returns null if no user action is needed
(rare), or a URL the browser needs to display for the user to beg/pay
for more time.
The browser could detect these well-known URLs in order to notify the
We should still use DHCP to return the address of the resource, so that
the CP does not need to proxy all IP traffic (it can just drop it, hooray).