Chrome routes http://0.0.0.0:* to Google Search(code.google.com)
code.google.com
Chrome routes http://0.0.0.0:* to Google Search
https://code.google.com/p/chromium/issues/detail?id=428046
17 comments
It's sad they're going to "fix" this. From the comments, it seems the only reason to support navigating to 0.0.0.0 is because some people got used to using that and they're getting confused or don't want to change their habits. This is the kind of accumulating crud that makes web browsers the ugly monsters they are, but it's not even of the important type like supporting non-standards-compliant websites. Imagine how the world would be a slightly better place if the Chrome guys asked Firefox etc to stop supporting 0.0.0.0 too, then people will stop blaming the browser and change their behavior.
This has nothing to do with "accumulating crud", it's a trivial thing, there's probably less code needed to not treat 0.0.0.0 differently. Also, the amount of people who have ever typed 0.0.0.0 into a browser is so small that it is virtually irrelevant what they do, and whether there is consistency between browsers.
But this is treating 0.0.0.0 differently. Did you not read the bug report, or the comments here, or anything? 0.0.0.0 is not a valid address. In fact, navigating to 127.0.0.1 when 0.0.0.0 is given in the URL is neither expected nor desirable.
[deleted]
No, it's the right thing to do.
If a large amount of users depend on a behavior, then you don't break it for a lousy "the specs says so" reason.
If a large amount of users depend on a behavior, then you don't break it for a lousy "the specs says so" reason.
Ha, I remember back when I first had Jekyll tell me to browse to http://0.0.0.0:NNNN/ and thinking "This can't possibly be correct, certainly that's invalid. Oh, it worked."
Glad I wasn't losing my mind, but this certainly is something people use, I guess it should probably be allowed.
That said, I think a local server that's listening on all interfaces/addresses should probably feel confident to say "please open http://localhost:NNNN" I've definitely seen neophytes to various tech get anxious about numbers appearing where they expect a name, and it's less clear what 0.0.0.0 is, if maybe it's something special and different from the "localhost" they're accustomed to (because it is... at least in theory).
Glad I wasn't losing my mind, but this certainly is something people use, I guess it should probably be allowed.
That said, I think a local server that's listening on all interfaces/addresses should probably feel confident to say "please open http://localhost:NNNN" I've definitely seen neophytes to various tech get anxious about numbers appearing where they expect a name, and it's less clear what 0.0.0.0 is, if maybe it's something special and different from the "localhost" they're accustomed to (because it is... at least in theory).
Imagine you are developing inside a VM but use the browser on the host OS to check the results. If the bind address was localhost then you would need to tunnel your connection from host to guest to be able to reach your server.
By binding to 0.0.0.0:PORT the guest OS will make your service available on all enabled interfaces:PORT combinations which, hopefully will "just work" in most use cases.
By binding to 0.0.0.0:PORT the guest OS will make your service available on all enabled interfaces:PORT combinations which, hopefully will "just work" in most use cases.
The right way for a server to do this is to listen on 0.0.0.0 and then examine the socket to see what address(es) it is listening on, and report a real address to the user. It's just laziness (or ignorance) to print 0.0.0.0.
Yep, exactly this. I do that in a Go app that I posted in my top level comment.
The difference is that 0.0.0.0 represents all addresses, while localhost is /one of/ those addresses.
Right, so it might make sense to go in the listen parameter of an app, but probably not for me to enter into my browser for how I get to that app.
Yeah 0.0.0.0 is a listening address, not a target.
not all addresses but all interfaces, which can have one or more addresses plumbed in.
i was always under the impression that 127.0.0.1 is what you should use
That would account for the case where my local machine doesn't have a host entry for "localhost" but would break if I don't have an IPV4 loopback (if, say, I only have a IPV6 one).
Both of those are pretty odd cases, so I'm not sure how much they're worth worrying about.
Both of those are pretty odd cases, so I'm not sure how much they're worth worrying about.
I could be wrong, because networking is Not My Thing At All, Oh God, Make The Pain Stop, Why Does The Routing Table Have Bees In It, but shouldn't 127.0.0.0/8 be able to find the IPv6 loopback if the IPv4 one does not exist? Or am I misunderstanding yet another part of networking?
Nope, perfectly possible to not have an IPV4 address.
$ sudo ifconfig lo 0
$ ifconfig lo
lo Link encap:Local Loopback
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING [... the rest omitted for brevity]
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
^C
--- 127.0.0.1 ping statistics ---
32 packets transmitted, 0 received, 100% packet lossInteresting. I guess I assumed it'd tack a bunch of zeroes on the front and try it as an IPv6 address. Thanks!
So, the point of localhost resolving to 127.0.0.1, is that it gives you a layer 3 address to route to the layer-1 loopback interface.
So... what interface does 0.0.0.0 resolve to? Is the loopback interface the default if a routing pattern match falls off the end of the route table? I really wouldn't expect that, given that the default of "no special subnet used" should end up routed out to the WAN.
So... what interface does 0.0.0.0 resolve to? Is the loopback interface the default if a routing pattern match falls off the end of the route table? I really wouldn't expect that, given that the default of "no special subnet used" should end up routed out to the WAN.
My understanding, and it could be wrong, is that 0.0.0.0 doesn't resolve to anything--no host, no interface. It's not valid at all. RFC 1122 clearly notes it as a MUST NOT address except as the source address when trying to figure out your own IP address; any behavior that such a resolution triggers is probably an undefined behavior of the network stack (unless it's explicitly and in a nonstandard way being handled, which feels odd to me).
That's right, RFC is really clear about this. What i don't get is why most browsers solve the address to 127.0.0.1 since it's incorrect as for specs.
Probably because of new developers. The last time I tried developing something in Django, it said it was running a webserver on 0.0.0.0:3000 or something similar. My classmate actually punched that into a browser, and it worked.
It's better if it doesn't work, so that they have to learn that it's very different from listening on the loopback. Accommodating the mistake encourages security holes.
I'd guess most applications that accept it replace it with 127.0.0.1 or resolve localhost. 0.0.0.0 is not a valid IP address and should be rejected by the network stack if passed in directly.
So everyone using hosts files with 0.0.0.0 to block ads is getting a face full of google now?
I don't know why you were downvoted. There's a very popular hosts file that redirects thousands of domains to 0.0.0.0 in order to block them.
Nope. Only entering the IP to Omnibar is affected by this.
It sounds like Chrome is just treating "0.0.0.0" as a string rather than as an address then?
Yes, as discussed in the link.
0.0.0.0 results in the input being interpreted as a search query rather than an address
0.0.0.0 results in the input being interpreted as a search query rather than an address
Incidentally, most browsers support decimal notation as well as dotted quad notation for IPv4 addresses. So http://1249764297/ works to reach Google for example. Once this regression is fixed you should be able to use http://0:*/ rather than http://0.0.0.0:*/
I say loopback address, you say 127.0.0.1. But did you know we dedicate the entire 127/8 Class A to it? That's a lot of loopback!
Another 'while I'm at it' question I've had for a while. Say you have a micro-service bound to local loopback, you don't want remote code touching it. E.g. I think the BitTorrent Sync WebUI will provide the private keys to any local loopback connection. It can't possibly be secure though, right?
Another 'while I'm at it' question I've had for a while. Say you have a micro-service bound to local loopback, you don't want remote code touching it. E.g. I think the BitTorrent Sync WebUI will provide the private keys to any local loopback connection. It can't possibly be secure though, right?
No reason it should be insecure (aside from the fact it's giving out the private keys at all). No network stack worth its salt is going to forward packets to 127/8 from outside, and while I often say routing is no substitute for firewalling, in this case there's an implicit firewall in the standards. It doesn't seem inherently any more dangerous than using a unix domain socket (still a socket), or a named pipe, or shared memory.
Actually, thought: can javascript running on a web page make AJAX requests to 127.0.0.1 and access this bittorrent sync thing? I'd think CORS would prevent it, but that might be a danger.
Actually, thought: can javascript running on a web page make AJAX requests to 127.0.0.1 and access this bittorrent sync thing? I'd think CORS would prevent it, but that might be a danger.
There's a trick of using DNS rebinding to bypass CORS and gain Javascript access to services on 127.0.0.1. Just another reason to make sure you check the Host header!
Yep. It's rather useful too. If you're simultaneously testing multiple services that expect to exclusively bind to a socket, you can set application a to listen on 127.0.0.1, and application b to 127.127.127.127. Beats stopping and restarting by a long shot.
Offhand, the BitTorrent Sync WebUI thing has a rather bad smell to it. There are ways to protect that info from getting out, but it's definitely suspect.
Offhand, the BitTorrent Sync WebUI thing has a rather bad smell to it. There are ways to protect that info from getting out, but it's definitely suspect.
Can't the services just listen on different ports?
For a lot of cases, yes. For cases of things like DNS resolvers, no. There's too much stuff that requires a specific port.
[deleted]
[deleted]
it seems like it could of been decided a lot earlier
who, when entering "http://*" would expect a search, and when entering "http://*.*.*.*:*" would still expect a search?
after that, it should let the lower levels respond with any error messages if there are (it is not the fault of firefox or chrome that it can be used as a destination address)
who, when entering "http://*" would expect a search, and when entering "http://*.*.*.*:*" would still expect a search?
after that, it should let the lower levels respond with any error messages if there are (it is not the fault of firefox or chrome that it can be used as a destination address)
Entering the address of 'all zeros' should probably transparently redirect to localhost. (If you're listening on all addresses, that should be the one; it should probably be treated as equivalent to a 302 redirect. (IE it should educate the user that the provided URI is being handled as localhost.))
I'd also like a shorter notation for 'this is not a search' I think ending a word in / is probably good enough for that?
I'd also like a shorter notation for 'this is not a search' I think ending a word in / is probably good enough for that?
I don't understand this line of thinking. 0.0.0.0 is not a valid routable IP address. It doesn't go anywhere. Why should it be magically redirected into the 127 /8? I would think we should disabuse people of their wrong notions rather than start juggling edge cases about our network routing.
I mean, I'm not saying it should go to Google Search, it should just go to a no-host-found page.
I mean, I'm not saying it should go to Google Search, it should just go to a no-host-found page.
Agree.
Making these kind of exceptions leads to more people doing illegal things, and then it's hard to know if you're doing something right because browsers won't help you figure out that you're breaking rules. Which makes everything more confusing.
Making these kind of exceptions leads to more people doing illegal things, and then it's hard to know if you're doing something right because browsers won't help you figure out that you're breaking rules. Which makes everything more confusing.
on linux-firefox, "http://0:*/" works like a charm
I believe it's a nice side-effect of the underling system because it also works on all cli programs (e.g. "ping 0")
I believe it's a nice side-effect of the underling system because it also works on all cli programs (e.g. "ping 0")
I favor "ping 2130706433" ;)
I just started noticing that in the last couple days and assumed it was a config issue.
[deleted]
Not just Jekyll:
∆∆∆: python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 ...
Listening on 0.0.0.0 is not the same as trying to navigate there. 0.0.0.0 (and [::]) are addresses reserved for listening on all interfaces; they are not routable IPs.
And? Did you read the thread? The complaint centered on trying to navigate to URLs that certain tools (e.g., Jekyll) tell users to hit. I was adding another example. (Looking over it again, I see that SimpleHTTPServer was actually mentioned, so that's my bad, but still.)
When used as a TCP destination address (on Linux at least), 0.0.0.0 is equivalent to 127.0.0.1, and :: is equivalent to ::1. The resulting connections will even pick 127.0.0.1/::1 as their source address, or fail to complete if no IPv4/IPv6 loopback address is configured.
There's also ::ffff:0.0.0.0 and ::ffff:127.0.0.1, which behave like their corresponding IPv4 addresses if IPV6_V6ONLY isn't enabled on the socket.
In any case, if you have server code that only listens on 0.0.0.0 (or ::ffff:0.0.0.0, if you're crazy), it's obsolete now because it's unable to accept IPv6 connections. A modern server should either listen on :: with IPV6_V6ONLY=0, or set IPV6_V6ONLY=1 and create two sockets listening on :: and 0.0.0.0.
One annoying thing about the socket API is that binding to loopback always requires two sockets, one for 127.0.0.1 (or ::ffff:127.0.0.1) and another for ::1.
And if you ever create a listen API that accepts "localhost:8080" as input, but only creates one socket for one address, then a pox on your house.
There's also ::ffff:0.0.0.0 and ::ffff:127.0.0.1, which behave like their corresponding IPv4 addresses if IPV6_V6ONLY isn't enabled on the socket.
In any case, if you have server code that only listens on 0.0.0.0 (or ::ffff:0.0.0.0, if you're crazy), it's obsolete now because it's unable to accept IPv6 connections. A modern server should either listen on :: with IPV6_V6ONLY=0, or set IPV6_V6ONLY=1 and create two sockets listening on :: and 0.0.0.0.
One annoying thing about the socket API is that binding to loopback always requires two sockets, one for 127.0.0.1 (or ::ffff:127.0.0.1) and another for ::1.
And if you ever create a listen API that accepts "localhost:8080" as input, but only creates one socket for one address, then a pox on your house.
That's only on Linux though, and I consider it a bug.
The RFCs are quite clear that 0.0.0.0 is unroutable and cannot be connected to. Windows gets this right.
Yeah, that's really misleading output from jekyll.
My own tool outputs [1] something like this:
Which are the two IPs that are reachable when I do http.ListenAndServe(":8080") in Go, and they're copy-pasteable into a browser without needing it to recognize invalid IPs.
[1] https://github.com/shurcooL/cmd/blob/8d16351d1f01caca2ac65b9...