<hat-free>
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
endpoint.
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