Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let 'localhost' be localhost

tools.ietf.org

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Let 'localhost' be localhost

#101

Post by rsync »

inopinatus wrote: post #10

Isn't there a problem here? This draft says: IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services. So let's say…

"You're left inventing workarounds such as your own namespace for loopbacks, or changing the service to also bind to, say, 127.1.1.1."

I don't understand this - you say you are "left with" an entire /8 that is universally recognized as the loopback ... what more could you want ?

I am genuinely curious - what is the utility of having lots of different network address ranges to define as the loopback ?

Re: Let 'localhost' be localhost

#102

Post by deathanatos »

rgacote wrote: post #56

And please make it 127.0.0.1 and not ::1. I've found several instances where localhost resolved to ::1.

It resolves to both on most major OSs, and I think it should as long as something isn't horribly misconfigured.

Most networking code on Unix-like OSes should (eventually) boil down to something like a call to getaddrinfo(2), a system call that returns the set of addresses that match a query — typically a hostname. The result set for localhost will often include both ::1 and 127.0.0.1, but the result from the function also includes what type of address (IPv4 or IPv6, essentially) they are: you're supposed to take both the address (such as ::1) and the address family (such as IPv6) and pass them to socket(2). (and if that fails, try the next one in the list)

This mechanism lets you resolve domains that might be IPv4 or IPv6 only, and not even need to care in the code: if the domain is IPv4 only, then getaddrinfo only returns addrinfos w/ IPv4 addresses. Likewise for v6. You forward the information to socket(2) and connect(2), and don't ever need to deal with a concrete addrinfo object.

Re: Let 'localhost' be localhost

#103

Post by wolfgke »

syntheticnature wrote: post #93
Raphmedia wrote: post #64

Earlier quoted context omitted.

While some people might edit their host for nefarious purposes, I think it's wrong to attribute all of it to malice. Personally, I set the host file to use https://github.com/StevenBlack/hosts in order to block ads on every computers I touch. I also often use software that manage the host file and ignore the default physical file.

The relevant part of the GP might be "since these customers don't know what they're doing."

Relevant (source: http://catb.org/jargon/html/koans.html):

A novice was trying to fix a broken Lisp machine by turning the power off and on.

Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”

Knight turned the machine off and on.

The machine worked.

Re: Let 'localhost' be localhost

#104

Post by joshka »

Scarblac wrote: post #50
near wrote: post #44

Nice! I'm very much in favor of this change. I develop my webserver locally, and it has many subdomains. So I have "www.localhost", "files.localhost", "doc.localhost", etc. I have to add each subdomain to my /etc/hosts file before I can use it, as you can't have wildcards in that file. And even then, if I type a new one into Chromium, it will try and redirect me to a Google search result, unless I prefix the whole th…

I wish whoever owns localhost.org (which resolves to 127.0.0.1) configured it so that *.localhost.org also worked. Would help with the browsers too.

For another memorable one try .localtest.me See http://readme.localtest.me/ for more details.

Re: Let 'localhost' be localhost

#105

Post by tokenizerrr »

darfs wrote: post #49
jabl wrote: post #13

Earlier quoted context omitted.

Like the linked wikipedia article says, .local is used by mDNS(zeroconf/bonjour/avahi/etc.), so you might see weird stuff if you use it for a "normal" DNS environment. AFAICT current "best practice" for private networks is to use a private subdomain of your real domain. Say, .internal.example.com.

That's why i use sometimes simply .loc.. :)

The annoying part is that Chrome treats valid (g)TLDs differently. If you type test.dev in your browser it will try to resolve test.dev. But if you type test.loc, it will google for test.loc.

There are a lot of workarounds sure, but try explaining that to everyone else.

Re: Let 'localhost' be localhost

#106

Post by tokenizerrr »

parenthephobia wrote: post #86
tokenizerrr wrote: post #23

Earlier quoted context omitted.

Google registered the .dev gTLD for their internal use. So I've been doing the same, hijacking all requests for the .dev gTLD and serving up my own zones.

That's fine until Google buys your company. :)

I am willing to take that risk. :)

Re: Let 'localhost' be localhost

#107

Post by brohee »

rsync wrote: post #101
inopinatus wrote: post #10

Isn't there a problem here? This draft says: IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services. So let's say…

"You're left inventing workarounds such as your own namespace for loopbacks, or changing the service to also bind to, say, 127.1.1.1." I don't understand this - you say you are "left with" an entire /8 that is universally recognized as the loopback ... what more could you want ? I am genuinely curious - what is the utility of having lots of different network address ranges to define as the loopback ?

Mocking machines for testing is one reason.

Re: Let 'localhost' be localhost

#108

Post by nitrogen »

drostie wrote: post #74
near wrote: post #44

Nice! I'm very much in favor of this change. I develop my webserver locally, and it has many subdomains. So I have "www.localhost", "files.localhost", "doc.localhost", etc. I have to add each subdomain to my /etc/hosts file before I can use it, as you can't have wildcards in that file. And even then, if I type a new one into Chromium, it will try and redirect me to a Google search result, unless I prefix the whole th…

You know that you do not need to use that naming convention, right? You might as well set up domains for www.pocalhost, files.pocalhost, doc.pocalhost. Or, why even have that part at all? You can just as easily set up the hosts record in /etc/hosts for www, and then visit http://www/ and it should work just fine on both Windows and Linux.

I'm guessing there might be a cookie or content security policy that requires testing with actual subdomains, so www alone might not work for their usecase. It's also nice to use a name that is guaranteed not to have conflicts, so localhost might be preferable for that reason.

Re: Let 'localhost' be localhost

#109

Post by IMcD23 »

WorldMaker wrote: post #59
nalllar wrote: post #54

Earlier quoted context omitted.

> it will try and redirect me to a Google search result, unless I prefix the whole thing, eg " http://doc.localhost/" Shortcut to avoid being redirected to a search for uncommon TLDs: end with a /, no need for the http:// .

Similarly you can start with just a //, no need for the http:.

Starting with // doesn't work in all browsers, such as Safari.

Re: Let 'localhost' be localhost

#110

Post by andreareina »

gant wrote: post #35

I always thought it made sense to address local VMs with .localhost domains in my hostsfile. Apparently not?

I've taken to having my VMs support mDNS (specifically avahi on Debian), and I can connect to .local without adding an entry to my hosts file or messing with DNS.
Post reply on HN