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

Sample Server - Strange CMD output (Failed to listen on Host:Port) - but site gets served (W8 and OSX) #249

Closed
MartinMajewski opened this Issue Jun 27, 2013 · 8 comments

Comments

Projects
None yet
4 participants
@MartinMajewski

MartinMajewski commented Jun 27, 2013

Hello,

with vibe.d 0.17.16 I've finally managed to compile my first vibe.d trial using the first steps' examples from the vibe.d page.

However, I receive the following command line messages from the server after start

on Windows 8

Listening for HTTP requests on :::8080
Listening for HTTP requests on 0.0.0.0:8080
EMPTY LINE

but on Mac OS X

Listening for HTTP requests on :::8080
Failed to listen on 0.0.0.0:8080
EMPTY LINE

The EMPTY LINE text implies that the server is running within a loop and must be killed with Ctrl+c.

Firing up my browser and navigating to "localhost:8080" does return my example site also on OS X. So the server seams to be running correctly. So what is the actual problem? Just an output-bug?

@mihails-strasuns

This comment has been minimized.

Show comment
Hide comment
@mihails-strasuns

mihails-strasuns Jun 27, 2013

Contributor

It does mean that it listens on IPv6 address and has failed to listen on IPv4 one (which is not fatal, as at least one listener exists).
That is somewhat strange, I usually have seen those errors other way around.

Contributor

mihails-strasuns commented Jun 27, 2013

It does mean that it listens on IPv6 address and has failed to listen on IPv4 one (which is not fatal, as at least one listener exists).
That is somewhat strange, I usually have seen those errors other way around.

@mihails-strasuns

This comment has been minimized.

Show comment
Hide comment
@mihails-strasuns

mihails-strasuns Jun 27, 2013

Contributor

Ah, I think that is similar but different - looks like currently on linux when one binds on :::, resulting listening socket accepts also IPv4 requests. Surprising but explain the warning message.

Contributor

mihails-strasuns commented Jun 27, 2013

Ah, I think that is similar but different - looks like currently on linux when one binds on :::, resulting listening socket accepts also IPv4 requests. Surprising but explain the warning message.

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Jul 3, 2013

Member

I think we should change the examples to use "127.0.0.1" as the only bind address and maybe even change the default value for HTTPServerSettings.bindAddresses to ["127.0.0.1"]. It's the safer default and avoids the confusion.

Member

s-ludwig commented Jul 3, 2013

I think we should change the examples to use "127.0.0.1" as the only bind address and maybe even change the default value for HTTPServerSettings.bindAddresses to ["127.0.0.1"]. It's the safer default and avoids the confusion.

@mihails-strasuns

This comment has been minimized.

Show comment
Hide comment
@mihails-strasuns

mihails-strasuns Jul 3, 2013

Contributor

@s-ludwig Does not sound really good idea given the fact how hard poor network engineers work to eliminate IPv4 legacy on WAN (I have been on that side of barricades!) :) Incorporating knowledge about OS listening socket behaviour may be uglier in the source code but looks much more beneficial to the end user in the long run to me.

Contributor

mihails-strasuns commented Jul 3, 2013

@s-ludwig Does not sound really good idea given the fact how hard poor network engineers work to eliminate IPv4 legacy on WAN (I have been on that side of barricades!) :) Incorporating knowledge about OS listening socket behaviour may be uglier in the source code but looks much more beneficial to the end user in the long run to me.

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Jul 3, 2013

Member

It would just be localhost and not be accesible from the WAN anyway. But maybe using ["::1", "127.0.0.1"] does not lead to the same conflict as ["::", "0.0.0.0"] and would be a better alternative? I guess it's worth a try...

Member

s-ludwig commented Jul 3, 2013

It would just be localhost and not be accesible from the WAN anyway. But maybe using ["::1", "127.0.0.1"] does not lead to the same conflict as ["::", "0.0.0.0"] and would be a better alternative? I guess it's worth a try...

@SerialVelocity

This comment has been minimized.

Show comment
Hide comment
@SerialVelocity

SerialVelocity Aug 13, 2013

On Mac

Works:
["::1", "0.0.0.0"]
["::1", "127.0.0.1"]
["::", "127.0.0.1"]

Doesn't work:
["::", "0.0.0.0"]

Hope this helps.

SerialVelocity commented Aug 13, 2013

On Mac

Works:
["::1", "0.0.0.0"]
["::1", "127.0.0.1"]
["::", "127.0.0.1"]

Doesn't work:
["::", "0.0.0.0"]

Hope this helps.

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Aug 14, 2013

Member

Thanks! So ["::1", "127.0.0.1"] seems to be a good route, I'll try that out on Linux and Windows and make the change if it works. (edit: corrected the IPv4 address)

Member

s-ludwig commented Aug 14, 2013

Thanks! So ["::1", "127.0.0.1"] seems to be a good route, I'll try that out on Linux and Windows and make the change if it works. (edit: corrected the IPv4 address)

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Sep 5, 2013

Member

Change made in 2fb92b7 works also on Linux as far as I have tested.

Member

s-ludwig commented Sep 5, 2013

Change made in 2fb92b7 works also on Linux as far as I have tested.

@s-ludwig s-ludwig closed this Sep 5, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment