[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] API access and .well-known
Right, I neglected to mention that option. Call it (d) link relations.
You might also do the reverse in the API-first arrangement that Tommy
suggests (API at the URL, HTML at the other end of a link relation).
It seems likely that 7710 deployment is scant enough that we would be
free to make this decision without being constrained to deal with
backwards compatibility.
One likely deployment involves the thing that is configured being
different to the thing that ultimately serves the content (for reasons
of sorting out the UE identification, if nothing else), so it's
possible that Adam's suggestion here doesn't add round trips that
weren't already needed.
On Wed, Jan 17, 2018 at 9:44 AM, Adam Roach <[email protected]> wrote:
> [as an individual]
>
> 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 client), but that doesn't seem to be the case here.
>
>
> On 1/14/18 11:39 PM, Martin Thomson wrote:
>
> a. use .well-known and just provide better justification for it
> b. use content negotiation
> c. find some way to get two URIs, like revising 7710 or finding an
> alternative mechanism (such as the one in RFC 5986)
>
>
> For what it's worth, I don't think (a) is possible -- I don't believe any
> plausible justification text can be put together that explains why other
> approaches are infeasible.
>
> Something else to consider is serving up the HTML portal on the endpoint you
> get from RFC7710, and including a link-relation [RFC5988] header field that
> points to the API; e.g.:
>
>
> HTTP/1.1 200 OK
> Link: <https://portal-api.example.com/json/>;rel="capport-api"
> Content-Type: text/html
>
> <!DOCTYPE html PUBLIC ...
> <html>...
> [legacy portal page goes here]...
> </html>
>
>
> Importantly: clients interested only in the API can simply perform a HEAD
> rather than a GET to retrieve the Link information. I'll note that this
> provides a clear extension point if you decide you need yet a third thing to
> be discoverable and/or need different HTTP endpoints for versioning in the
> future. I do note that it requires an additional round trip, similar to the
> redirection approach that has been discussed in conjunction with content
> negotiation. Notably, taking this approach eliminates the need for
> redirects, since the link header can point to any arbitrary URL.
>
> /a