Re:Chrome routes http://0.0.0.0:* to Google Search
by eropple on Saturday February 14, 2015 @02:05AM
(#9048976)
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).
Re:Chrome routes http://0.0.0.0:* to Google Search
by hjeldin on Saturday February 14, 2015 @02:10AM
(#9048985)
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.
Re:Chrome routes http://0.0.0.0:* to Google Search
by shitlord on Saturday February 14, 2015 @02:25AM
(#9049016)
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.
Re:Chrome routes http://0.0.0.0:* to Google Search
by firethief on Saturday February 14, 2015 @04:14AM
(#9049174)
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.
Re:Chrome routes http://0.0.0.0:* to Google Search
by detaro on Saturday February 14, 2015 @02:06AM
(#9048978)
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... 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.