51–60 of 179 posts
If this doesn't happen or takes too long, there's always lacolhost.com and *.lacolhost.com. I own this domain, have registered it out until 2026 and vow that the domain and all subdomains will always redirect to localhost. It's easy to type and easy to remember and should always do a good job of expressing intent of usage.
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…
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…
If you're on a POSIX system, I'd argue that this is a bug in the client. Typically, the client should call getaddrinfo(3); as part of that, the application would either specify directly that it's only interested in AF_INET results, or just filter out non-AF_INET results.
(Further, if you support IPv6 in the client, and thus request such results from getaddrinfo, you should skip to the next result if the connection fails.)
On the server, you can also bind to both the IPv4 and the IPv6 addresses. If you listen to ::, you should get IPv4 connections too. (Through this[1] mechanism.)
[1]: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...
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…
I always have local.my company.com DNS that resolves to 127.0.0.1. I can get a valid cert that way too.
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.
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
But even if we force Docker to bind to only IPv4, curl will still work:
docker run --rm -p 127.0.0.1:8080:80/tcp nginx:latest
* Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 8080 failed: Connection refused
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
[1]: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...
Can anybody with more knowledge point out techniques that this would break? Are there any software or networking patterns that currently rely on localhost _not_ resolving to the loopback? EDIT: The RFC mentions that MySQL currently differentiates between the two, but that's it.
www.localhost.mydomain.com?
Can anybody with more knowledge point out techniques that this would break? Are there any software or networking patterns that currently rely on localhost _not_ resolving to the loopback? EDIT: The RFC mentions that MySQL currently differentiates between the two, but that's it.
Within " .localhost. "... www.localhost.mydomain.com?