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

You're correct that it's also possible to encode the VSOCK information in the URI as `http://1234567:123/...`. But you don't have a clear indication that the authority uses the VSOCK address family, and it could easily be misinterpreted as an INET authority with `1234567` as a registered name instead.

By the same argument, a UDS authority at `/path/to/socket` could be encoded as `http://%2Fpath%2Fto%2Fsocket/...` without your proposed extension. But that also leaves the address family implicit, and definitely has the readability of a square peg in a round hole. :)

I'm trying to say that your proposal makes progress by allowing a path as a port as well as a number, but I think IF we're going to propose a URI syntax change, it should have deeper impact and provide enough flexibility to support other address families nicely as well.

(And to be clear I'm personally not enthusiastic at this point about a URI syntax change, given the `IPvFuture` extension in 3986, which already does something similar, doesn't seem to be widely implemented AFAICT. I do think it may be productive to propose standard ways to encode authorities from more address families in the existing syntax, so multiple URI schemes such as http/https/ftp/smtp/... that operate on arbitrary stream interfaces could agree on standard approaches.)

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

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