Hi,
On 2016-01-18, at 23:07, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com> wrote:
It is natural for the client resolving alice(_at_)example(_dot_)com to use the
following Web Service Endpoints:
http://host1.example.com/.well-known/mmm/
http://host2.example.com/.well-known/mmm/
In effect we are providing the SRV prefix to the HTTP server using the
URI request line in the same way that we use the Host: header to tell
the server which service is being accessed (example.com in either case
as following the prcedent set for CNAME lookup. we give the original
DNS query name, not the internal DNS translations).
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
signature.asc
Description: Message signed with OpenPGP using GPGMail