wrangler dev seems to be only listening on ipv6?

[iameli]

🐛 Bug Report

Environment

• operating system: macOS 10.15.3
• output of rustc -V: not using Rust, installed Wrangler from NPM
• output of node -v: v10.19.0
• output of wrangler -V: 👷 ✨ wrangler 1.8.4

Steps to reproduce

In one tab:

wrangler dev

In another:

▶ curl --ipv4 http://localhost:8787
curl: (7) Failed to connect to localhost port 8787: Connection refused

What did you expect to see?

The worker

What did you see instead?

Connection refused message

This one totally baffled me for a while until I realized I had my script configured to hit 127.0.0.1 and wrangler dev was only listening on IPv6. Is this intentional? I can work around it if it is.

EDIT: Looks like this can be worked around with --ip 127.0.0.1.

[EverlastingBugstopper]

Hey @iameli - that's a great find! Going to do some investigating to see how trivial it would be to get wrangler dev listening on both ipv4 and ipv6. Thanks for the report 😄

[EverlastingBugstopper]

@iameli - I'm going to close this as won't do. unfortunately I can't figure out a good way to do this without allowing requests from non-loopback ips which would be a security issue. I think the workaround is sufficient in this case, provide an ip with the --ip flag to use ipv4.

[transitive-bullshit]

Please re-open this issue as this has me puzzled for hours.

The same problem repros for Node.js HTTP requests, and this DNS issue is something that I've never encountered with any other dev / localhost servers.

Example using got's dnsLookupIpVersion:

These all fail:

got('http://localhost:8787/test')

got('http://localhost:8787/test', { dnsLookupIpVersion: 'ipv4' })

fetch('http://localhost:8787/test')

This works but is an awkward and unnecessary workaround:

got('http://localhost:8787/test', { dnsLookupIpVersion: 'ipv6' })

What makes this such a nasty bug is that it was really difficult to track down since ECONNREFUSED on the client-side is so opaque and no amount of logging within the server helps. I also spent a while thinking it might be a CORS issue.

[EverlastingBugstopper]

unfortunately there doesn't seem to be a way for me to expose wrangler dev on both ipv4 AND ipv6 without also exposing your development server to your local network, which could be a security vulnerability at a coffee shop or something. i'll open a PR to make it listen on IPv4 by default and not print "localhost". If you'd like it to listen on both, you can specify --ip [::]

[transitive-bullshit]

Thanks @EverlastingBugstopper 🙏 😄

[normanr]

You can do this without exposing to the local network, but it requires that you create multiple TcpListeners (one for 127.0.0.1 and one for ::1).

The preferred way to do this is to call getaddrinfo and then bind to all of the returned addresses. Either hint SOCK_STREAM, or filter the returned results for SOCK_STREAM socktypes. Also you could probably pass None for the hostname instead of Some("localhost"), as long as you do not set the passive flag (otherwise it will return the any address instead of the loopback address).

[ericdraken]

wrangler dev -ip :: was the only thing that worked when I wanted to curl the [IPv4]:8787 of the Docker container of wranger@beta running. The result is "Listening at http://:::8787", however. [wrangler 0.0.24]

[aboodman]

I'm seeing this currently with wrangler 2.0.24. Is it expected?

Connecting to 127.0.0.1 does not work, but connecting to ::1 does. It took me a really long time to track this down.