Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Master crashes when opening two apps (and port conflicts) #2112

Closed
gaearon opened this issue May 10, 2017 · 13 comments
Closed

Master crashes when opening two apps (and port conflicts) #2112

gaearon opened this issue May 10, 2017 · 13 comments

Comments

@gaearon
Copy link
Contributor

gaearon commented May 10, 2017

This is some new issue.

screen shot 2017-05-10 at 5 33 37 pm

@Timer
Copy link
Contributor

Timer commented May 10, 2017

This regression was introduced when we fixed the behavior of our HOST binding. detect-port does not support specifying an address to check on, so we need to switch packages or send a PR upstream to add the functionality.

tl;dr we listen on 127.0.0.1, detect-port checks on 0.0.0.0

@Timer
Copy link
Contributor

Timer commented May 10, 2017

Filed an issue upstream: node-modules/detect-port#19.

@gaearon
Copy link
Contributor Author

gaearon commented May 10, 2017

Hmm. If we're listening on 127.0.0.1, does it mean access from local network doesn't mean by default anymore? This seems frustrating. Why did we change this?

@Timer
Copy link
Contributor

Timer commented May 10, 2017

We've always said we're listening on localhost which implies we're not listening on the entire local network. Mainly, it was done out of interest in security (since we proxy API calls which are going to be elevated during development).

Previously we said localhost but actually listened on 0.0.0.0.

I'm not opposed to listening to 0.0.0.0 by default.

@Timer Timer added this to the 0.10.0 milestone May 10, 2017
@gaearon
Copy link
Contributor Author

gaearon commented May 10, 2017

I'd prefer we keep the existing behavior with using 0.0.0.0 as a default. I'm cool with printing 0.0.0.0 to the console in this case for posterity.

@Timer
Copy link
Contributor

Timer commented May 10, 2017

Fair enough, the 0.9.x branch currently does this (and prints 0.0.0.0). I'll send a PR.

@Timer
Copy link
Contributor

Timer commented May 11, 2017

Opened #2117; that issue still doesn't solve this issue because Node's default behavior is to bind to IPv6, not IPv4. We might want to follow suit, but it's a bit more involved than specifying :: or 0:0:0:0:0:0:0:0.

@gaearon
Copy link
Contributor Author

gaearon commented May 11, 2017

Um. I still don't quite get it. Can we just revert to old behavior in the meantime? Or was that fix important?

@Timer
Copy link
Contributor

Timer commented May 11, 2017

It's important because HOST doesn't work otherwise, the issue was already fixed in detect port so we just have to update the dependency and this should start working again.

@gaearon
Copy link
Contributor Author

gaearon commented May 11, 2017

Okay. Can you take care of this?

@Timer
Copy link
Contributor

Timer commented May 11, 2017

#2126

@Timer
Copy link
Contributor

Timer commented May 14, 2017

#2147

@Timer
Copy link
Contributor

Timer commented May 15, 2017

Fixed via #2147

@Timer Timer closed this as completed May 15, 2017
@lock lock bot locked and limited conversation to collaborators Jan 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants