On 19/01/2016 6:35 PM, "Eggert, Lars" <lars@xxxxxxxxxx> wrote:
>
> as a reviewer for the ports registry, we frequently see requests for port assignments for services over HTTP/HTTPS where the applicant states that port 80/443/8080/etc. are already "taken". So they want to be able to use URLs with a fixed port other than those.
>
> To cater to their needs without assigning more ports for HTTP, I floated a slightly different proposal with a few people, namely, to extend the "port" component in the URL scheme and allow a service name there. The browser could then look that up against the given host with DNS-SD and connect on the returned port.
>
> scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]
>
> I don't feel strongly about this variant either. I would love to see some scheme that would allow folks to run HTTP services on arbitrary dynamic ports without burning more port numbers. Happy to help write something up.
>
> Lars
I'm feeling a little doughy after a long day of staring at logs. Is this idea to allow folk to mint a URL like "http://example.com:foo/" and have the UA use example.com's DNS to look up what port 'foo' is?
Presumably because example.com is running a server on some random port, which speaks a particular protocol-over-HTTP. Other folk might know that the protocol-over-HTTP is 'foo', but not know what random port it's served over on this machine at this time.
I like the idea of avoiding a query to a mundane (non-foo-speaking) web server whose whole purpose is just to tell you where to go to speak 'foo', or even the need to have such a thing. Can DNS-SD tell you what path to query (along with server and port), in case the foo-speaking part of the server is nested within the regular port-80 web server?
I also like that it means you don't have to split up your 'foo' (most of it served on port :foo, but some running on port :80 under /.well-known/)