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

51–60 of 117 posts

Re: Let 'localhost' be localhost

#51

Post by mcherm »

yeezul wrote: post #47

What if I develop something on localhost, and two months later I decide I want to test/implement a feature on Android/iOS. Do I have to remap my whole localhost development in order to be able to access my localhost from a tablet?

Yes.

Let me try wording this differently for you. "What if I develop something with only local calls between my front and back ends, and later I decide I want to test/implement a front-end feature on Android/iOS which doesn't support running the back end. Do I have to change my development so it is no longer local?" - the answer is yes.

On the other hand, "remap my whole localhost development" is a REALLY impressive-sounding way of saying "change the one line in the config file that says to connect to 'localhost' to connect to 'api.myhost.com' instead." Or maybe, if you are a sloppy developer, "use search-and-replace to replace all instances of 'localhost' in the code with 'api.myhost.com'." Either way, it is a trivial change.

Re: Let 'localhost' be localhost

#52

Post by noinsight »

tokenizerrr wrote: post #23
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.

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.

Google has both .dev and .prod.

Re: Let 'localhost' be localhost

#53

Post by theandrewbailey »

okket wrote: post #48
lambda wrote: post #39

I have had a number of customers who have broken our applications, which have daemons listening on localhost, by editing their /etc/hosts files and removing the localhost entry. I guess various people edit /etc/hosts to prevent applications from talking to licensing servers, and in the process happen to accidentally blow away the localhost entry (since these customers don't know what they're doing). We had this happe…

Looks like we need eternal IPv4 support, if it is just for 127.0.0.1 :(

I was expecting IPv4 to be around forever, for similar reasons that COBOL and the still emulated 8254 PC beep are: there's too much critical infrastructure using it.

Re: Let 'localhost' be localhost

#54

Post by nalllar »

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…

> 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://.

Re: Let 'localhost' be localhost

#55

Post by imtringued »

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.

You can use xip.io

127.0.0.1.xip.io www.127.0.0.1.xip.io files.127.0.0.1.xip.io doc.127.0.0.1.xip.io

all resolve to 127.0.0.1

Re: Let 'localhost' be localhost

#57

Post by yaur »

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.

I use 42foo.com which does exactly that.

Re: Let 'localhost' be localhost

#59

Post by WorldMaker »

nalllar wrote: post #54
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…

> 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:.

Re: Let 'localhost' be localhost

#60

Post by jerf »

mikewest wrote: post #32
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…

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. I don't mean to overconstrain the definition of loopback. If you have a good mechanism for specifying a specific IP range as loopback, and…

"If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)"

Currently where it says "an IP loopback addresses", it may be worth saying something like "any of the IP loopback addresses for the device".

I agree that technically "an IP loopback address" ought to be sufficient, but I have also found it is a very common belief, probably even the majority belief, among people who use networking that "127.0.0.1" is the one and only loopback address. (I've lost count of the systems I've slightly broken just by feeding them 127.1.1.1 or equivalent.) I'm sure people who are the sort to read and write standards know better, but since it doesn't hurt the standard itself to emphasize the point, perhaps it's worth it.

Post reply on HN