On 19/01/2016 6:35 PM, "Eggert, Lars" <lars(_at_)netapp(_dot_)com> 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/)