Time to use AF_UNIX

What’s wrong with a new scheme, e.g. httpu:? Analogous to https: being HTTP over TLS, httpu: is HTTP over unix-domain.

The issue of conformance to RFC 3986 would be solved, as the authority is specific to several schemes, and each scheme is free to specify its own syntax; if a slash-free authority is desired, the same proposed solutions such as percent-encoding can be used, but other easier-to-read solutions will still conform.

The issue remains of differentiating which path components refer to the socket versus the HTTP path, but this can be solved, including by the same manner as the other proposals in this thread.

But, a new scheme would greatly reduce the ambiguity and confusion, both for URL parsers and humans looking at the URL, over using http:, file:, or re-using other schemes.

The difference in cognitive load in trying to determine, at a quick glance, what a URL refers to, in particular that it’s over a unix-domain socket, between some of the proposals in this thread, e.g.

http://%2Fvar%2Frun%2Fexample/foo/bar
file:///var/run/example:unix/foo/bar

and e.g. something like:

httpu:///var/run/example:/foo/bar

or:

httpu://{/var/run/example}/foo/bar

or:

httpu://%2Fvar%2Frun%2Fexample/foo/bar

As a new scheme, the number of leading slashes is now open for modification as well, the extra slashes being a mistake per Tim Berners-Lee, although I favor leaving them for consistency, hence retaining the cognitively familiar:

httpu:///absolute/path:/bar
httpu://~user1/foo.socket:/bar

Rather than the simpler but unfamiliar:

httpu:/absolute/path:/bar
httpu:~user1/foo.socket:/bar

It might complicate sending HTTP over TLS over unix-domain, but I’m having difficulty imagining a use-case for this.

It does not generalize to other protocols such as ftp, imap, etc., unless the same naming convention is used there (as has already been done with the “s” suffix). It also doesn’t apply to custom protocols over unix-domain sockets, but in general custom protocols either will have custom URL formats, or not use a URL at all to refer to the service.

Both of the above-mentioned drawbacks exist equally for all of the file: proposals, and in fact are worse since they don’t specify a protocol.

All that said, given that Linux has a “fast path” that eliminates the TCP protocol when connecting to localhost, something that I only learned from reading the comments on this article, the need for HTTP over unix-domain seems much less useful to me – I’ll be looking into that.