27 ms·
Chrome routes http://0.0.0.0:* to Google Search
- lotyrin 12y agoHa, 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 12y agoThe difference is that 0.0.0.0 represents all addresses, while localhost is /one of/ those addresses.
- lotyrin 12y agoRight, 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 12y agoYeah 0.0.0.0 is a listening address, not a target.
- ukigumo 12y agonot all addresses but all interfaces, which can have one or more addresses plumbed in.
- hayksaakian 12y agoi was always under the impression that 127.0.0.1 is what you should use
- lotyrin 12y agoThat 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.
- eropple 12y agoI 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?
- lotyrin 12y agoNope, 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 loss
- eropple 12y agoInteresting. I guess I assumed it'd tack a bunch of zeroes on the front and try it as an IPv6 address. Thanks!
- ukigumo 12y agoImagine 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.
- enneff 12y agoThe 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.
- shurcooL 12y agoYep, exactly this. I do that in a Go app that I posted in my top level comment.
- mjevans 12y agoEntering 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 12y agoI 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 12y agoAgree. 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 12y agoSo, 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 12y agoMy 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 12y agoThat'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 12y agoProbably 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 12y agoIt'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.
- detaro 12y ago
- kijeda 12y agoIncidentally, 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:*/
- deleted 12y ago[deleted]
- disposablename 12y agoSo everyone using hosts files with 0.0.0.0 to block ads is getting a face full of google now?
- okasaki 12y agoI 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 12y agoNope. Only entering the IP to Omnibar is affected by this.
- fenomas 12y agoIt sounds like Chrome is just treating "0.0.0.0" as a string rather than as an address then?
- madeofpalk 12y agoYes, as discussed in the link. 0.0.0.0 results in the input being interpreted as a search query rather than an address
- shurcooL 12y ago0.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/8d16351d1f01caca2ac65b9c276ff4c19b27118a/gopherjs_serve_html/main.go#L31-L50 https://github.com/shurcooL/cmd/blob/8d16351d1f01caca2ac65b9...
- asdfaoeu 12y agoListening on 0.0.0.0 is different to listening on multiple IP addresses when considering pulling up new interfaces afterwards.
- __derek__ 12y agoNot just Jekyll: ∆∆∆: python3 -m http.server Serving HTTP on 0.0.0.0 port 8000 ... Edit: formatting
- pushrax 12y agoListening 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__ 12y agoAnd? 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.)
- zaroth 12y agoI 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?
- Sanddancer 12y agoYep. 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 12y agoCan't the services just listen on different ports?
- Sanddancer 12y agoFor a lot of cases, yes. For cases of things like DNS resolvers, no. There's too much stuff that requires a specific port.
- lmm 12y agoNo 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.
- drumdance 12y agoI just started noticing that in the last couple days and assumed it was a config issue.
- p1mrx 12y agoWhen 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 12y agoThat'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 12y agoIt'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 12y agoThis 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 12y agoBut 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 12y ago[deleted]
- Phil_Latio 12y agoNo, 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.
- anh79 12y agoOn my Linux boxes, ping 0.0.0.0 resolves to 127.0.0.1.
- anh79 12y agoEven curl works with 0.0.0.0 (127.0.0.1). So Chrome please do that ^^
- RubyPinch 12y agoit 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)
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- _lce0 12y agoon 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 12y agoI favor "ping 2130706433" ;)