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

First of all I like your approach.

But maybe to explain the reasoning behind this thing:
> So, while "http+unix:" is a valid RFC 3986 "scheme", the desired protocol there is simply "http", and there is no reason to define an entire new group of RFC 7595 "schemes" which have nothing to do with the protocol itself. That would entail not just "http+unix:", but also "https+unix:", "ftp+unix:", "smtp+unix:", "submissions+unix:", etc., etc., and on and on.

there could as well be a good usecase for adding lower layer protocol information ot hte RFC 3986 schema. The "+" could be defined as a delimiter for lower level protocols (But that wouldn't free us from having to change the authority parsing to allow for a more generic representation).
So standardizing the "+" delimiter this way would also allow us to do things like "https+ipv6://www.google.com".
Or now with the introduction of quic potentially also "https+tcp://www.google.com".

Now why am I taking time to explain this. Well, your approach is mostly good. But this part `host = IP-literal / IPv4address / "unix" / reg-name` won't work well in practice. Well it would be better than now. But it still doesn't take into account features like SNI... Therefore instead of your suggestion of having "unix" in the host part and the socket path in the port field, I'd suggest having the DNS/SNI name in the host part. The Socket in the port field and the information about what lower layer protocol should be used added to the schema part. That way we could also standardize that the schema part influences the parsing of the port field.
(Thinking of this it would also allow other stuff that would come in handy for development and testing like: `https+ipv4://www.example.com:127.127.200.2:443/`, basically getting rid of host file overwrites for mocking within CI pipelines. But if this is desirable is another topic of its own)

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

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