Chrome routes http://0.0.0.0:* to Google Search

https://code.google.com/p/chromium/issues/detail?id=428046

by bcjordan • 11 years ago

45 55 11 years ago

code.google.com

lotyrin5• 11 years ago

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

mjevans2• 11 years ago

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

lotyrin5• 11 years ago

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.

alex_duf• 11 years ago

Yeah 0.0.0.0 is a listening address, not a target.

ukigumo2• 11 years ago

not all addresses but all interfaces, which can have one or more addresses plumbed in.

hayksaakian• 11 years ago

i was always under the impression that 127.0.0.1 is what you should use

lotyrin5• 11 years ago

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.

ukigumo2• 11 years ago

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.

lotyrin5• 11 years ago

I'm not recommending anyone change the address they listen on by default. Certainly the wildcard is a sensible default for the reasons you mention.

_lce02• 11 years ago

binding to localhost also prevents others on the lan to access your service, like you phone over wifi

enneff• 11 years ago

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.

shurcooL3• 11 years ago

Yep, exactly this. I do that in a Go app that I posted in my top level comment.

mjevans2• 11 years ago

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?

eropple5• 11 years ago

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.

shurcooL3• 11 years ago

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.

derefr• 11 years ago

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.

eropple5• 11 years ago

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• 11 years ago

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.

detaro• 11 years ago

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.

asdfaoeu2• 11 years ago

0.0.0.0 works fine on Linux in connect() and just goes to 127.0.0.1 as one would expect.

kijeda• 11 years ago

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

disposablename• 11 years ago

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

okasaki• 11 years ago

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.

keletappi• 11 years ago

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

fenomas• 11 years ago

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

shurcooL3• 11 years ago

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

asdfaoeu2• 11 years ago

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

__derek__2• 11 years ago

Not just Jekyll:

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

Edit: formatting

pushrax• 11 years ago

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__2• 11 years ago

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

zaroth2• 11 years ago

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?

Sanddancer2• 11 years ago

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.

yuvipanda• 11 years ago

Can't the services just listen on different ports?

lmm• 11 years ago

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.

zaroth2• 11 years ago

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!

drumdance• 11 years ago

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

p1mrx• 11 years ago

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• 11 years ago

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.

Potando• 11 years ago

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• 11 years ago

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• 11 years ago

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.

Phil_Latio• 11 years ago

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.

anh792• 11 years ago

On my Linux boxes, ping 0.0.0.0 resolves to 127.0.0.1.

anh792• 11 years ago

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

RubyPinch• 11 years ago

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)

_lce02• 11 years ago

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")

Quai• 11 years ago

I favor "ping 2130706433" ;)

Chrome routes http://0.0.0.0:* to Google Search

Related Stories