Change localhost to 127.0.0.1:8080/

[nengo]

Change localhost to 127.0.0.1:8080/

[jgosmann]

Can you provide more details? I think, 'localhost' is more future-proof because it can resolve to an iPv6 address (::1) instead of the IPv4 address.

[tcstewar]

Can you provide more details? I think, 'localhost' is more future-proof because it can resolve to an iPv6 address (::1) instead of the IPv4 address.

Ooo... good point. Forgot about that.

The problem was that on his machine somehow the browser refused to resolve localhost and went to http://www.localhost.com/ instead. I've never seen a computer do that before, and indeed, didn't even know it was possible.

[jgosmann]

One could argue that it is problem with his configuration. Maybe this one?

[tcstewar]

One could argue that it is problem with his configuration. Maybe this one?

Oh no.... that's exactly what's happening. We pop open the browser window slightly before the server gets started, and so if firefox tries to open up the page before the server is ready, it doesn't respond to the initial request, gives up, and tries localhost.com and www.localhost.com instead. Ouch.

So the real solution is to keep things aimed at localhost, but not call webbrowser.open() until after we're sure the server is ready. Otherwise we can hit this race condition.

[amaziying]

So I tried the solution on the link Jan posted. The localhost no longer resolves to www.localhost.com http://www.localhost.com/ but just localhost:8080 doesn’t work either. Only 127.0.0.1:8080 works for me…

On Jan 22, 2015, at 5:41 PM, tcstewar [email protected] wrote:

One could argue that it is problem with his configuration. Maybe this one?

Oh no.... that's exactly what's happening. We pop open the browser window slightly before the server gets started, and so if firefox tries to open up the page before the server is ready, it doesn't respond to the initial request, gives up, and tries localhost.com and www.localhost.com instead. Ouch.

So the real solution is to keep things aimed at localhost, but not call webbrowser.open() until after we're sure the server is ready. Otherwise we can hit this race condition.

—
Reply to this email directly or view it on GitHub #21 (comment).

[cchan987]

Websocket now queries the document.URL in order to connect websockets.

[tcstewar]

Websocket now queries the document.URL in order to connect websockets.

That's not the problem here. The problem is that the document URL itself doesn't work, not the websockets.

I haven't seen this problem in a while except on on Mac a few weeks ago. But the fix was still to manually go to http://127.0.0.1:8080 rather than http://localhost:8080

[jgosmann]

The IPython visualization waits until the server is started. So we might be able to reuse that code.

[tcstewar]

The IPython visualization waits until the server is started. So we might be able to reuse that code.

Possibly. I'd like to have access to a machine where the problem exists, though, before trying to debug it, as I'm not 100% convinced that it's a startup time thing.

[jgosmann]

How about inserting a sleep in the startup to see whether you can reproduce it? That doesn't guarantee that there is not an additional problem, but at least it allows to verify that part.

[tcstewar]

How about inserting a sleep in the startup to see whether you can reproduce it?

Ooo, good idea.. lemme try that...

Argh, nope, even with a 30-second sleep neither Firefox nor Chrome give up for me. And it was never anywhere close to that amount of time in previous situations I've seen this in.

[tcstewar]

So I think that puts me back to thinking this is an IPv4 vs IPv6 issue... it might have been on a machine that was treating localhost as ::1 instead of as 127.0.0.1, and I'm pretty sure I haven't turned on support for IPv6 in swi.py. So that might be all that's happening here.....

[Seanny123]

Is this resolved by #673?

[jgosmann]

No. It is still using localhost and does not support IPv6. Though, IPv6 support is easy to turn on, but the websocket implementation has to be change too to accept those connections (shouldn't be too complicated either).

[tcstewar]

This needs to get looked at again, especially since @jgosmann 's server refactoring. It'd be great to have IPv6 support. The initially reported issue seems very rare (and we don't currently have a machine that's exhibiting it), but my current belief is that if we had full IPv6 support, then the problem wouldn't happen.

[jgosmann]

Seems like we're currently not supporting IPv6. Replacing IPv4 with IPv6 support would probably be easy with 2 or 3 lines changed, but supporting IPv4 and IPv6 is a bit harder. Here are some links with helpful information:

• https://bugs.python.org/issue17561
• https://code.activestate.com/recipes/578504-server-supporting-ipv4-and-ipv6/

[jgosmann]

#864 adds dual stack IPv6 support. Not sure if that resolves this problem?

[jgosmann]

Did anyone see this problem in the last year or can this be closed?

[krisfrenette]

As far as I can tell, this issues hasn't come up again, and there has been no further update since the the last request so I am going to close this out.