Re: [Captive-portals] API access and .well-known

On Fri, Jan 19, 2018 at 9:33 AM, Adam Roach wrote: > Sure, either in a 3xx response; or, if we're using Link: relations, those > URLs can vary based on the client. If you want to get fancy about it, you > can even have your DHCP server hand out different URLs in the RFC7710

Re: [Captive-portals] API access and .well-known

On 1/18/18 4:18 PM, Michael Richardson wrote: Adam Roach wrote: > I agree that we should strictly avoid synthesizing URLs in general, > and should try to avoid .well-known URLs in particular. Sometimes > you're forced to use .well-known (e.g., when there's

Re: [Captive-portals] API access and .well-known

[as an individual] On 1/18/18 4:15 PM, Michael Richardson wrote: I think that we need the 7710 mechanism to get the HOST part, and that the URL part SHOULD be .well-known/blah, but MAY be something else. No, please don't. That's very much *not* what .well-known is meant for. See RFC 5785,

Re: [Captive-portals] API access and .well-known

Adam Roach wrote: > I agree that we should strictly avoid synthesizing URLs in general, > and should try to avoid .well-known URLs in particular. Sometimes > you're forced to use .well-known (e.g., when there's literally no way > to get a full URL to the

Re: [Captive-portals] API access and .well-known

Tommy Pauly wrote: > The benefit of this approach (get [API-URL] first, and follow it to > [HTML-URL]) is that we pave the way towards more flexibility when we > don’t necessarily need the [HTML-URL] to do traditional captive > portals, but instead can do