invalid url printed from simple loopback application

[sam-github]

Bug/Feature request

The application was basically copied from the yo loopback output for hello world:

 var loopback = require('loopback');
 var app = module.exports = loopback();

 app.start = function() {
   // start the web server
   return app.listen(process.env.PORT || 0, function() {
     app.emit('started');
     var baseUrl = app.get('url').replace(/\/$/, '');
     console.log('Web server listening at: %s', baseUrl);
     if (app.get('loopback-component-explorer')) {
       var explorerPath =
         app.get('loopback-component-explorer').mountPath;
       console.log('Browse your REST API at %s%s',
                   baseUrl, explorerPath);
     }
   });
 };

 const server = app.start();

Put that in a directory with no loopback directory structures, but loopback installed as a dep, and run it.

Output is

Web server listening at: http://:::44943

Which is an invalid URL.

Expected result

Additional information

node -e 'console.log(process.platform, process.arch, process.versions.node)'

linux x64 7.5.0

npm info loopback

loopback@3.2.1

node -e "require('net').createServer().listen().on('listening', function(){console.log(this.address())})"

{ address: '::', family: 'IPv6', port: 40399 }

@bajtos

also:

% ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c8:f7:33:db:8c:97 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.181/24 brd 192.168.0.255 scope global dynamic wlan1
       valid_lft 598556sec preferred_lft 598556sec
    inet6 fe80::7d2b:81c4:1f2:2ad/64 scope link 
       valid_lft forever preferred_lft forever
...

[bajtos]

@sam-github Good catch. I think this is a bug in the code building the host value, see

loopback/lib/application.js

Lines 543 to 561 in 304ecc4

	var host = self.get('host');
	if (!host) {
	listeningOnAll = true;
	host = this.address().address;
	self.set('host', host);
	} else if (host === '0.0.0.0' || host === '::') {
	listeningOnAll = true;
	}
	if (!self.get('url')) {
	if (process.platform === 'win32' && listeningOnAll) {
	// Windows browsers don't support `0.0.0.0` host in the URL
	// We are replacing it with localhost to build a URL
	// that can be copied and pasted into the browser.
	host = 'localhost';
	}
	var url = 'http://' + host + ':' + self.get('port') + '/';
	self.set('url', url);
	}

Because you are not using loopback-boot and the default server/config.json (which provides host value), we infer the host from this.address().address as ::, meaning "listening on all network interfaces". On IPv4, this is 0.0.0.0 on Unix, which gives us URL http://0.0.0.0:<port>/.

What is the IPv6 equivalent of http://0.0.0.0:<port>/?

[sam-github]

The IPv6 equivalent is http://[::]:<port>, but it doesn't work in Chrome, so I assumed it just didn't work at all, so I tried ::1 (explicit localhost IPv6), and that didn't work either...

Then I read this and tried with Firefox, and it does work, and tried the suggestion above, and it didn't work with Chrome. The CLI enable flag mentioned for Chrome didn't work for me (and wouldn't work anyhow for customers).

So, I'm at a loss. Google hates localhost IPv6?

On the other hand, on most systems, I think, an IPv6 address on :: can be reached via IPv4, or just http://localhost:<port>. Does any of that help?

[sam-github]

nodejs/node#9390 (comment) <--- looks relevant

[bajtos]

@sam-github thanks for the update. My take is that we should fix the code building the URL to detect ::-like addresses (::, ::1, etc.) and convert them to [::]-like host in the URL. Maybe we should treat :: in a special way and convert it to localhost to support Chrome, even if it means there may be inconsistency between :: used by listen() on the server and IPv4 address used by the Chrome browser.

Thoughts?

Would you like to contribute this fix yourself?

[sam-github]

@bajtos I'm sorry, I am overloaded, and don't have time to make the fix. It maybe isn't even a big deal, it seems I did something unusual? Maybe flag as "good first contribution"?

I don't think there is an inconsistency, listening on :: accepts connections to both IPv6 and IPv4, so whether http://localhost maps to ::1 or to 127.0.0.1, both will work. The only thing that won't work is that localhost may not resolve in DNS on Windows when there is no network adapter enabled... but this scenario is much less common than using Chrome, so we might have to accept it.

[bajtos]

Maybe flag as "good first contribution"?

Great idea, let's leave it at this :)

[jjhesk]

@sam-github @bajtos you can try to use the ipfox to check if the loopback server support ipv6. In my case, I got apple rejected from not being able to support NAT64 ipv6 and the loopback-boot is deployed and hosted on heroku. now I am trying to think if loopback has any configurations in coding to enabled ipv6 server listening. I also learned that HTTP Routing for ipv6 is not supported by heroku and does it mean i have nothing to do to fix it?

Consider that Cedar14 is deployed and used on my current host. Since I learned that Cedar is based on Ubuntu14.04. It should be supported according to this chart.

I looked at the configuration guide version 3.6.0 the latest iteration and I did not find any configurations to support ipv6 listen. Maybe we can add some additional text on it.

[watilde]

we might can close this issue as resolved by #3450 :)

[sam-github]

It looks like @bajtos fixed this to me, I'm OK with closing.