3 ms·
Yeah I don't think that comment aged too well. Not to mention the explosion of microservices and autoscaling temp services, this would be very useful.. I can ap
by bilekas 3y ago
Yeah I don't think that comment aged too well. Not to mention the explosion of microservices and autoscaling temp services, this would be very useful.. I can appreciate the reluctancy though, it's not a trivial change to get right.
- nine_k 3y agoWhat would make that change non-trivial, to your mind? Currently it can be achieved by a program as non-trivial as netcat Also I don't share their concerns about SNI. To my mind, the Host header can just be unsupported for Unix sockets. SNI makes sense when the several domain names resolve to the same IP address. This should not be an important, case with Unix sockets. Not supporting it is a much better compromise than not supporting Unix sockets at all.
- bilekas 3y agoI can't speak to the entire spec and quit frankly I don't know enough, but this comment seems to highlight some of the nuances that need to be considered https://github.com/whatwg/url/issues/577#issuecomment-1185345177 https://github.com/whatwg/url/issues/577#issuecomment-118534... It's not insurmountable absolutely and I would appreciate it absolutely.
- nine_k 3y agoI see that all these problems are interesting details. But I find them just that, details. Many of them can be ignored in an initial implementation, in a way that would allow to fill them in later, if need be. Somehow the lack of handling of all these subtleties does not preclude the file:/ scheme from being implemented. If there is a will, there is a way. I think the will is lacking here. The developers themselves do no care. I can see why the Chrome team is opposed to that: it's the Google's interest to eliminate all things offline. I didn't expect Mozilla folks to be so unreceptive though. Having the unix domain socket support would be a distinct advantage.