Re: [whatwg/url] Addressing HTTP servers over Unix domain sockets (#577)

I haven't read anything here that seems to justify breaking with the familiar pattern, "\<protocol>://\<domain>/\<filepath>" or injecting a lot of special characters into the URL, or mimicking an IPv6 address.  The protocol is simply "http".  The domain is right there in the name, "*Unix Domain* Socket".  Like any other top level domain - net, com, org - the domain is simply "unix".  I don't know any reason that a web browser application cannot parse the domain from a URL, recognize a nonstandard domain name, and invoke a special handler for a non-network socket.  The difficulty seems to be in distinguishing the path to the socket from the path to the resource file.

The "HTTP with socket path as the port" option, above, makes the most sense.  And since a special handler must already be invoked for this "unix domain", I expect that colons - ":" -  can continue to be used as the "port" separator for the socket path.

Altogether, that suggests a straightforward URL, as in: "http://unix:/var/run/server/ht.socket:/path/to/resource.html".

Is there any reason that those repeating ":/" character sequences would pose a problem in a URL?

This approach would not impose any limitation on the use of ":" in the resource path name, since a "unix domain" *must* be followed by a socket path, and that path will always be delimited by ":/".  Any subsequent colons must then be part of the resource path name.

And, of course, this URL format still supports specifying any arbitrary protocol, served through a unix domain socket.  And there is nothing redundant or misleading in the URL, as would be the case with any format requiring the name "localhost" or involving special parameter passing.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/577#issuecomment-1183599307
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/577/1183599307@github.com>