web URI method

One of my big regrets with HTTP is that it does not use the DNS SRV
mechanism for service discovery. Which is hardly surprising because SRV was
invented later. The mx record already existed and we didn't see the need.

DNS round robin is a work-around that is totally inferior. But much water
under the bridge, I cannot see how we get SRV to work reliably as a
discovery mechanism for http:/https: at this point.

But what if we assign a completely new method and define it as using the
full DNS service discovery mechanism? So if someone enters web://
example.com/ it will pull the DNS TXT and SRV records and work out that it
should be using the QUIC protocol on host1.example.com port 783 or
host2.example.com port 834.

DNS service discovery is already a standard:

https://www.rfc-editor.org/info/rfc6763/


Now this might sound like it is too late to be of use to anyone but it
could be enormously useful for Web services. And in particular for the use
case where Web Services go off onto their own presentation protocol rather
than piggybacking on HTTP which is designed to support Web browsing. Almost
everything that HTTP does for Web Services is done by QUIC. But how do we
provide a transition path?

This would be of immediate use to me because I have a rather extensive home
network with 80 active IP addressable devices (after a cull) and five
static IP addresses. I have multiple services in the house on their own
proxmox vm and I can reach each of them internally on port 443. If I want
to expose them on the Internet I have to configure a reverse proxy which
means unnecessarily introducing another point of failure and creates a
bottleneck if I am running jellyfin or the like.

With the web: URI method, I can set up my split horizon DNS so that I can
type web://homeassistant.hallambaker.com/ and have it work either inside or
outside the house without having to remember any port number.

Inside the house:

homeassistant 10.0.0.80:443
jellyfin: 10.0.0.81:443

Outside the house

homeassistant 96.237.102.38:8123
jellyfin: 96.237.102.38:8920

web:/homeassistant.hallambaker.com/ and web://jellyfin.hallambaker.com/ to
work for both.

The less I have to remember, the less chance of making an administrative
glitch that costs me half an hour of working out what went wrong. (All
computer errors are stupid mistakes after you find them.) In the short
term, I have to use a browser extension for the web: method but that isn't
hard. If other people find use, it will make its way into the stock
browsers.


While my setup is somewhat high end, I think we can do a lot better for the
average consumer with some slightly more intelligent DNS services. I also
think there are a lot of companies offering DynDNS today that could provide
a lot more value if we did a bit of usability improvement.

I can write up a draft, wanted some input from here first. It seems pretty
obvious to me that the only possible use for web is something that is going
to be a superset of http/https. But folk might have plans.