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

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

[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

[legacy portal page goes here]...

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.