On 25 June 2018 at 16:50, Brannon Dorsey <bran...@brannondorsey.com> wrote:
> As far as I see it, a > domain name should never be allowed to respond with a private IP address > moments after it first responded with a public IP address. > If I understand correctly, this is exactly what we plan to do on our Mozilla IoT gateway <https://iot.mozilla.org/gateway/> project. The use case <https://github.com/mozilla-iot/gateway/issues/171> we have is for a Web of Things gateway in the home to continue to be accessible locally over HTTPS when the Internet goes down. In our current implementation a user's Web of Things gateway can be reached securely over the Internet via https://foo.mozilla-iot.org or insecurely over the local network via http://gateway.local. We want it to be possible for the gateway to still be accessible locally when the home Internet connection goes down (e.g. so that you can still turn on your lights!), but for that to use HTTPS rather than plain HTTP. The current proposed solution <https://github.com/mozilla-iot/gateway/issues/171#issuecomment-398855965> to this problem is to use an Alt-Svc HTTP header (RFC 7838) which tells the browser to load resources from https://gateway.local rather than https://foo.mozilla-iot.org when gateway.local is available. The idea is that the browser will then cache that response so it will always try the local IP first, so it will still work without an Internet connection for as long as the cache lives. As an added bonus, the user can always use the same web address whether they're inside or outside the network, and always get the fastest route. We're currently in the process of implementing this, and we're not sure yet whether it will work, but if it does this could be a use case that we wouldn't want Firefox to block. (Daniel's comments about DNS-over-HTTPS are a bit concerning). Ben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
