Open (-o) option now defaults to http://0.0.0.0

[timmhayes]

Steps to reproduce the issue, if applicable. Include the actual command and output and/or stack trace.

Run the following simple command:
http-server -o some-page.htm

What did you expect to happen?
I expect http-server to open some-page.htm automatically in my browser using a valid local address (http://127.0.0.1/some-page.htm)

What actually happened?
My browser opened to an empty page on http://0.0.0.0:8080/some-page.htm

Tell us about your environment

• exact http-server version:: 13.0.1
• Node version:: 14.15.2
• Platform:: Win 10

Other information (related issues, suggestions for a fix, etc):
This issue just popped up when I updated from v0.12.3 to 13.0.1 and it is caused by issue #615 and pull #642. After some research, I realized I can fix it by adding the address to use -a to my command line arguments like so...

http-server -o some-page.htm -a http://127.0.0.1

But the -o option previously worked without specifying the address. Shouldn't the server still default to 127.0.1 if no address is specified? As far as I can tell, all that pull request was supposed to do was to allow users to set the address to 0.0.0.0, not make it as the new default. But if this was intentional, perhaps you should note in your documentation that the -o option should now be used with the -a option.

[thkruz]

Replicated on http-server 13.0.0, Node 16.9.0 and Win 10.

Reading the README it is clear that 0.0.0.0 is the default, but much like OP I recommend that 127.0.0.1 is used as the default even if the pull request to allow 0.0.0.0 to be used remains. It is far more intuitive.

I am using -a 127.0.0.1 without the http:// and everything works fine for both http and https.

[timmhayes]

Funny, I missed that note in the README, but it looks like that was added to the README 10 years ago in 8fe1ac8 and it wasn't the default with the -o argument until the recent change was made above.

[kimbaudi]

I'm also experiencing this issue. Here is my npm script:

http-server public -p 4488 -P http://127.0.0.1:4488? -o

or

http-server public -a 0.0.0.0 -p 4488 -P http://127.0.0.1:4488? -o

Although this allows me to access within my LAN (which is what I want), it opens my webpage locally in http:0.0.0.0 (which I don't want).

If -a is set to 0.0.0.0 or omitted, can the address automatically default to 127.0.0.1 so it opens up correctly in the browser while still allowing access to our webpages across the LAN?

I also don't want to set -a 127.0.0.1 because I can no longer access my webpages across the LAN (even though it will open up correctly in the browser).

[thornjad]

I'm unable to reproduce this, but I don't have access to a Windows machine, so it might be Windows-specific, it would appear the OS isn't handling 0.0.0.0 properly and we may need to hold its hand.

When using -o and it opens to http://0.0.0.0, if you manually go to http://127.0.0.1 is it running there? Or is it not, which would be a bigger issue?

[kimbaudi]

I'm unable to reproduce this, but I don't have access to a Windows machine, so it might be Windows-specific

this is most likely a windows-specific issue.

When using -o and it opens to http://0.0.0.0, if you manually go to http://127.0.0.1 is it running there?

Yes, manually going to http://127.0.0.1 works.

I just tested on my windows machine using the command http-server public -p 4321 -P http://127.0.0.1:4321? -o and I get the following output:

$ yarn serve
yarn run v1.22.11
$ http-server public -p 4321 -P http://127.0.0.1:4321? -o
Starting up http-server, serving public

http-server settings: 
CORS: disabled
Cache: 3600 seconds
Connection Timeout: 120 seconds
Directory Listings: visible
AutoIndex: visible
Serve GZIP Files: false
Serve Brotli Files: false
Default File Extension: none

Available on:
  http://192.168.xxx.1:4321
  http://192.168.1.xxx:4321
  http://127.0.0.1:4321
Unhandled requests will be served from: http://127.0.0.1:4321?
Hit CTRL-C to stop the server
open: http://0.0.0.0:4321

[timmhayes]

It works fine at http://127.0.0.1. But it is tedious to see a "This site can’t be reached" message each time I launch with the -o argument, then need to manually navigate to that address. This is not a huge issue, but I posted it because it previously worked without having to do this and the recent code change I listed above broke it.

I'm also on Windows.

[thornjad]

I'm unable to test on a Windows machine, could anyone see if the fix in #728 works?

[kimbaudi]

I just tested on windows and the fix in #728 works.

$ yarn link http-server
yarn link v1.22.11
success Using linked package for "http-server".
Done in 0.09s.

$ yarn serve
yarn run v1.22.11
$ http-server public -p 4321 -P http://127.0.0.1:4321? -o
Starting up http-server, serving public

http-server settings: 
CORS: disabled
Cache: 3600 seconds
Connection Timeout: 120 seconds
Directory Listings: visible
AutoIndex: visible
Serve GZIP Files: false
Serve Brotli Files: false
Default File Extension: none

Available on:
  http://192.168.xxx.1:4321
  http://192.168.1.xxx:4321
  http://127.0.0.1:4321
Unhandled requests will be served from: http://127.0.0.1:4321?
Hit CTRL-C to stop the server
Open: http://127.0.0.1:4321

It opens at http://127.0.0.1:4321 instead of http://0.0.0.0:4321

[thornjad]

Wonderful! This will be fixed in a patch version to be released later today