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

I do think there's a good case here for making authority specification more flexible.

I find @thx1111's proposal roughly appealing, as I agree that the current numeric port section is overly biased for specific protocols. At the same time, extending it to only support socket paths as well (or at least a path-like value) feels like it fails to prevent future instances of the same problem for other host schemes. My preference would be to ignore the port for protocols where it isn't useful and instead focus on scheme-specific authority syntax refinement.

As a data point, though, I thought I would go with the `http://[v1.uds:/tmp/mysock]/foo/bar` option in my current POC, since it looked like it would work based on RFC 3986. However, I found that Java's `java.net.URI` parser still rejected it, because it was only customized to support IPv6 addresses in square brackets and not the `IPvFuture` option: https://bugs.openjdk.org/browse/JDK-8019345. Given that, I'm pessimistic that support for any URI format change will percolate through the various existing URI parsers in my lifetime, given RFC 3986 is already 20 years old! 

I suspect a supplementary RFC proposing standard ways of embedding alternative kinds of authorities in the existing URI host syntax will be more useful in practice. This could be referenced by extensions to existing schemes like `http:`, without necessarily splitting off explicit sub-schemes like `http+unix:`. 

FWIW, in my POC I'm finding something building on the `...uds.localhost` idea, with an abstraction that maps symbols like `foo.bar.blarg.uds.localhost` to `<UDS root by blarg organization and OS conventions>/bar/foo` is working out fairly nicely.

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

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