
Chrome routes http://0.0.0.0:* to Google Search - bcjordan
https://code.google.com/p/chromium/issues/detail?id=428046
======
shurcooL
0.0.0.0 is not a valid destination ip, but it is one of common variations used
when binding a listening socket to "all/any addresses", aka INADDR_ANY, or
addr strings like ":8080", etc..

    
    
        > Yes, I ment to navigate to 0.0.0.0 to test the jekyll generated website.
        > That's where jekyll points me to (console output says
        > "Server address: http://0.0.0.0:4000/" It works just fine on all browsers but
        > the latest Chrome.
    

Yeah, that's really misleading output from jekyll.

My own tool outputs [1] something like this:

    
    
        serving, available at:
        http://localhost:8080/index.html
        http://10.0.0.10:8080/index.html
    

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...](https://github.com/shurcooL/cmd/blob/8d16351d1f01caca2ac65b9c276ff4c19b27118a/gopherjs_serve_html/main.go#L31-L50)

~~~
asdfaoeu
Listening on 0.0.0.0 is different to listening on multiple IP addresses when
considering pulling up new interfaces afterwards.

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

~~~
ambrop7
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.

~~~
belovedeagle
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.

------
lotyrin
Ha, I remember back when I first had Jekyll tell me to browse to
[http://0.0.0.0:NNNN/](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"](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).

~~~
mjevans
The difference is that 0.0.0.0 represents all addresses, while localhost is
/one of/ those addresses.

~~~
lotyrin
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.

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

~~~
eropple
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).

~~~
hjeldin
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.

~~~
shitlord
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.

~~~
firethief
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.

------
disposablename
So everyone using hosts files with 0.0.0.0 to block ads is getting a face full
of google now?

~~~
keletappi
Nope. Only entering the IP to Omnibar is affected by this.

~~~
fenomas
It sounds like Chrome is just treating "0.0.0.0" as a string rather than as an
address then?

~~~
madeofpalk
Yes, as discussed in the link.

0.0.0.0 results in the input being interpreted as a search query rather than
an address

------
kijeda
Incidentally, most browsers support decimal notation as well as dotted quad
notation for IPv4 addresses. So [http://1249764297/](http://1249764297/) works
to reach Google for example. Once this regression is fixed you should be able
to use [http://0:*/](http://0:*/) rather than
[http://0.0.0.0:*/](http://0.0.0.0:*/)

------
zaroth
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?

~~~
lmm
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.

~~~
zaroth
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!

------
RubyPinch
it seems like it could of been decided a lot earlier

who, when entering "[http://*"](http://*") would expect a search, and when
entering "[http://*.*.*.*:*"](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)

------
mjevans
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?

~~~
eropple
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.

~~~
shurcooL
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.

------
eridal
on linux-firefox, "[http://0:*/"](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")

~~~
Quai
I favor "ping 2130706433" ;)

------
drumdance
I just started noticing that in the last couple days and assumed it was a
config issue.

------
anh79
On my Linux boxes, ping 0.0.0.0 resolves to 127.0.0.1.

~~~
anh79
Even curl works with 0.0.0.0 (127.0.0.1). So Chrome please do that ^^

------
__derek__
Not just Jekyll:

    
    
      ∆∆∆: python3 -m http.server
      Serving HTTP on 0.0.0.0 port 8000 ...
    

Edit: formatting

~~~
pushrax
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.

~~~
__derek__
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.)

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

~~~
ynik
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.

