Internet Draft: Let 'localhost' be localhost

Post by wfunction » Tue, Aug 08, 2017, 7:17 AM UTC

rnxrx wrote: post #109

wfunction wrote: post #103

Earlier quoted context omitted.

Yeah you're right, it certainly does. I would be curious if it goes mainstream enough to replace IPv4 in the foreseeable future though, which was its intention.

It's been quite mainstream in certain contexts and geographies for a number of years now. As an example - most handsets on modern LTE (and newer) networks have been strong-majority v6 for quite a while. The fact that this hasn't been obvious is an argument in favor of v6's success.

Post by pawelk » Tue, Aug 08, 2017, 7:27 AM UTC

disiplus wrote: post #140

jonathonf wrote: post #9

I've had web browsers perform a web search for 'localhost', or even just redirect me to localhost.com. Annoying.

chrome does this. if i dont specify http or https before domain chrome will try to search any .dev or .loc or ... domain with googe search engine. anoying

Post by alexellisuk » Tue, Aug 08, 2017, 7:29 AM UTC

deathanatos wrote: post #57

alexellisuk wrote: post #53

Localhost resolving to IPv6 basically breaks with Docker they unless you give special instructions only listens on IPv4. With curl for instance you can use the -4 parameter but probably best we start saying test the site on 127.0.0.1 in tutorials.

Sorry, but none of that is correct. First, if you publish a container's port in docker, such as with the -p flag, e.g., docker run --rm -p 8080:80/tcp nginx:latest Docker will listen, on the host, on ::; it will accept IPv4 connections on that bind. (Through IPv4-mapped IPv6 addresses[1], which is a transition mechanism.) But even if we force Docker to bind to only IPv4, curl will still work: docker run --rm -p 127.0…

Post by alexellisuk » Tue, Aug 08, 2017, 7:41 AM UTC

alexellisuk wrote: post #145

deathanatos wrote: post #57

Earlier quoted context omitted.

Sorry, but none of that is correct. First, if you publish a container's port in docker, such as with the -p flag, e.g., docker run --rm -p 8080:80/tcp nginx:latest Docker will listen, on the host, on ::; it will accept IPv4 connections on that bind. (Through IPv4-mapped IPv6 addresses[1], which is a transition mechanism.) But even if we force Docker to bind to only IPv4, curl will still work: docker run --rm -p 127.0…

I'm sorry but none of what you've said is correct - I'm speaking from experience from the Docker community. Watch this ASCII recording to see the issue https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU We run into the issue on RPi/Raspbian - curl hangs indefinitely. I had someone report to me that he couldn't access localhost:8080 in a web-browser using a Docker container for FaaS because it was resolving to this IPv…

Post by user5994461 » Tue, Aug 08, 2017, 8:46 AM UTC

p1mrx wrote: post #97

user5994461 wrote: post #25

First, the lack of confidence that "localhost" actually resolves to the loopback interface encourages application developers to hard-code IP addresses like "127.0.0.1" in order to obtain certainty regarding routing. This causes problems in the transition from IPv4 to IPv6 (see problem 8 in [draft-ietf-sunset4-gapanalysis]). That does remind me of the times I was dealing with weird connection issues in some critical s…

Ideally, a server binding to "localhost" should create a listening socket for each of its IP addresses (e.g. 127.0.0.1 and ::1), and a client connecting to "localhost" should try each IP address in order, until one succeeds. But a lot of standard libraries (including parts of Java and Go) get this wrong, and pick exactly one IP address arbitrarily. When you combine a buggy client with a buggy server, and their prefer…