3 ms·
I lost a lot of the blind faith I had in people who make http servers when I realized some network configurations just can't be expressed. Like next.js's "Prod
by mac-chaffee 5y ago
I lost a lot of the blind faith I had in people who make http servers when I realized some network configurations just can't be expressed.
Like next.js's "Production Server"[1] uses Node's builtin server, which doesn't natively let you listen on more than one IP. And because next.js hardcodes 0.0.0.0, it doesn't also listen on the IPv6 equivalent if available, which breaks some clients when using "localhost" as the hostname (BusyBox wget as a notable example I found).
[1]: https://nextjs.org/docs/api-reference/cli#production https://nextjs.org/docs/api-reference/cli#production
- fuzzy2 5y agoBut then Busybox wget is simply broken, sorry. It’s still entirely normal for a hostname to resolve to both IPv4 and IPv6 addresses, yet have some services not listening on both. Good TCP clients implement a fallback mechanism that could be so fast the user doesn’t even notice.
- jeroenhd 5y agoI've encountered a similar failure, when some old process still claimed [::]:80 when I restarted the web server, probably a lingering socket or something like that, which made the new process only bind to 0.0.0.0:80. It took me a while to find out why my changes weren't being reflected when I could see the binding _right there_ in `ss -tlpn`! Honestly, I don't think it's too unreasonable to argue that if a client has IPv6 connectivity and a hostname has a valid AAAA record, the connection should be established over IPv6. Browsers tend to have fallbacks to IPv4, but outside browsers you'll be surprised how little actual system software cares about DNS fallback. Reading the BusyBox source code (https://elixir.bootlin.com/busybox/latest/source/libbb/xconnect.c#L176 https://elixir.bootlin.com/busybox/latest/source/libbb/xconn...) it seems like it will pass AF_UNSPEC to str2sockaddr, which is packed into `addrinfo hint` and then passed on to getaddrinfo(). Only when IPv6 support is disabled or ENABLE_FEATURE_PREFER_IPV4_ADDRESS is enabled will busybox shuffle around the DNS results to return an IPv4 address. If your service isn't available on IPv6 yet your hostname has a valid IPv6 record, it's your task to indicate this to the software (using the -4 flag, for example) or to configure it to retry.
- Dylan16807 5y agoThat fallback is a workaround. Requiring it is simply broken.
- mac-chaffee 5y agoIf BusyBox did implement that kind of fallback, they'd need to set a default timeout. So the whole thing would still be broken because every other request would be delayed by the timeout.