[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
