[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


I quite like this option.  If we use this approach then it seems to me
host-side implementations can choose their level of support, right?

    [A] super basic HTML view interaction

Makes a GET for the RFC 7710 URL, ignores any Link relation, serves up
the HTML to the human.

    [B] HTML + Link support

Makes a GET for the RFC 7710 URL, notices the Link relate, and starts
a connection to the API endpoint for not really too much more cost
than following a 3xx redirect (especially if the HTML is structured
such that a webview would need to fetch lots of extra resources, which
the API-following code path could avoid loading).

    [C] some kind of clever HTML + Link support

Makes a HEAD for the RFC 7710 URL.  If there is no Link header try to
re-use the existing TCP connection to issue a GET and serve HTML to
the human.  If there is a Link relation, start a connection to the API

Do I understand things correctly, is this reasonable?

On 17 January 2018 at 11:16, Martin Thomson <[email protected]> wrote:
> 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
> _______________________________________________
> Captive-portals mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature