localhost address

[keepsimple1]

It seems that by default localhost would be resolved into ipv6 address only (MacOS):

aioquic/src/aioquic/asyncio/client.py

Line 62 in 229c0f1

addr = infos[0][4]

infos[0] is ipv6 info (not dual-stack). Is this intended?

This is ok when running the server from this repo as it's binding to ipv6. But it will not work (by default) when connecting to a server that runs on "127.0.0.1:4433" or "0.0.0.0:4433".

[jlaine]

If you're in a dual-stack environment, yes IPv6 is preferred. I'm not sure I understand your point, if you force IPv4 on the server side, sure you'd better make sure the client also uses IPv4.

[keepsimple1]

What I am trying to say is that, localhost should work for both dual-stack and IPv4-only.

Yes if it's a dual-stack server, the current client code works. But if the server is listening on IPv4, the client fails to connect to localhost.

[jlaine]

You're going to have to be more explicit, I still don't understand the issue.

• if you're on a dual stack host, it all works out of the box

• if you don't have IPv6 support, why would localhost resolve to an IPv6 address?

[keepsimple1]

The scenario is that the host has dual stack support, and the server is running locally on the host using endpoint 127.0.0.1:4433.

Now run the client locally as well, specifying server endpoint using localhost:4433, and it won't work as it resolves to an IPv6 address.

Now I realize that this is one of the quirks on a dual-stack host, as you said, preferring IPv6 here when resolving the name localhost. It can be confusing though, particularly to a person not familiar with IPv6.

A side note, looks like curl does this differently (Mac OS X dual stack host), it still connects to a local IPv4 server when using localhost.

[jlaine]

OK, I see what you mean, it's possible to create a non-working case. I'm not sure how you'd like to see things improved, any suggestions?

[keepsimple1]

I would suggest that if IPv6 connect fails (refused), fallback to IPv4. More general speaking, connect to the preferred address family first, and if refused, fallback to the 2nd address family (if exists).

On MacOS, it seems that telnet does that:

$ telnet localhost 6142
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host

[jlaine]

Before jumping into this kind of change, could you have a look at the QUIC draft RFC and see if there is a standard behaviour defined for this?

[keepsimple1]

I looked at QUIC draft 27 and did not find standard behaviors defined for this. There is "preferred_address" frame but it's after the handshake so it's a different thing.

[abnvsally]

Is there a way to run the client from browser in mac . It all runs on terminal but I cant connect the sever through browser it says cannot connect to local host.