Re: web URI method

Maybe you’re aware but RFC9460 HTTP/SVCB DNS does some of this already and has been implemented to varying degrees in the major browsers with Apple providing more comprehensive support. Though it can be tricky getting fallout behaviour correct if, for example, the path doesn’t full support QUIC.



> On 4 Jun 2026, at 18:54, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> External: Think before clicking
> 
> 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/ <http://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 <http://host1.example.com/> port 783 or host2.example.com <http://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/ <http://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 <http://10.0.0.80:443/> 
> jellyfin: 10.0.0.81:443 <http://10.0.0.81:443/>
> 
> Outside the house
> 
> homeassistant 96.237.102.38:8123
> jellyfin: 96.237.102.38:8920 <http://96.237.102.38:8920/>
> 
> web:/homeassistant.hallambaker.com/ <http://homeassistant.hallambaker.com/> and web://jellyfin.hallambaker.com/ <http://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.