Yesterday we encountered a slight nuance in the node 18 HTTP client. We use CSS locally in development and testing, so most client_id in OIDC flow are on some port on a localhost. It turns out that node 18 prefers ipv6 when making requests to localhost so at the list on Mac OS we had to pin node to 16 when running CSS.

There must be a way to avoid node 18 HTTP client making requests to localhost using ipv6 but we ended up pinning node 16 (we use volta) to be able to work on a demo app rather than wrestling with node 🐱

Today I will try the --dns-result-order=ipv4first solution from:

• "localhost" favours IPv6 in node v17, used to favour IPv4 nodejs/node#40537

It looks like node 20 already addressed it:

• net: add autoSelectFamily option nodejs/node#44731

I didn't check the linked issues yet, but shouldn't that also cause issues in the CSS IDP integration tests then as those also use localhost?

I haven't looked at how you have those tests set up. Yesterday we noticed that ClientID document served using ng serve on http://localhost:4200 was causing requests from CSS to fail, on the other hand, ClientID document served from the storage of the CSS worked just fine.

EDIT: It might be also possible that in CI env localhost only resolves to IPv4 and has separate ip6-localhost for IPv6

I think this PR is perfectly fine, especially since one should be able to pin node 20 when working on localhost. I just wanted to give heads-up that some developers might start encountering ECONNREFUSED ::1: during the OIDC flow, depending on how they serve their ClientID document (assuming they don't just use DynReg)

Just a thought — could whatever generates the requests to localhost that resolve to use IPv6 address ::1: instead send those requests to the specific IPv4 address, 127.0.0.1, skipping the localhost name resolution entirely?

@TallTed I think one could choose to use 127.0.0.1 instead of localhost, I think the latter will use Unix Domain Socket while the former will always use TCP/IP (at least on some operating systems). I think that the main factor here is developer familiarity with common setups and localhost is commonly used.

I can confirm that while mentioned issue occurs with node 18, as mentioned in one of the linked issues node 20 uses RFC 8305 (Happy Eyeballs algorithm) and pining to node 20 solved it for me (just as pinning it to node 16 did yesterday).

I would just recommend developers pining their node to 20 while they work on localhost, at least to run CSS, volta, and similar tools make it very easy.