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

Lots of different proposals have been made above:

* Changing the URL syntax
* Adding a new DNS TLD
* Appending a suffix to the URL scheme
* Defining a new URL scheme

Changing the URL syntax requires coming up with a solution for _all_ URLs, not just HTTP. Backwards compatibility needs to be considered for a very large ecosystem, and incremental deployment needs to be considered. As Anne said above, these factors raise the bar _considerably_ for any proposal, and so should be a last resort (there's currently an effort by IPv6 people to do a similar thing, and it's not going well for these reasons).

Creating a new TLD for one protocol isn't good architecture, and a lot of people are going to push back on it. Again, a proposal in this area is likely to hit friction from other, unrelated communities (in this case, DNS).

Appending a suffix to the URL scheme implies that the suffix makes sense for other URL schemes. This means that wider review and discussion will need to take place to get it adopted.

That makes defining a new URL scheme the approach that's most likely to succeed. Such a scheme could define itself to use an authority that is _not_ grounded in DNS, so it could be something like:

> httpu://tmp.mysock/path/to/resource?query&string

Defining it as a new scheme would also provide an opportunity to answer a lot of questions like "is HTTP/1 or HTTP/2 used"? "does it use TLS"? and so on.

But that's just my opinion.

If there's interest in solving this problem, I'd suggest that someone write a document outlining a proposal and bring it to the [IETF HTTP WG](https://httpwg.org) - there are are larger diversity of HTTP implementers represented there that can provide feedback.


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

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