Seems like a TCP/IP stack issue rather than a browser issue... 0.0.0.0 is not supposed to be a valid address (in fact, no IPv4 address with 0 as the first octet is a valid destination IP). The network stack should be dropping those packets.
0.0.0.0 is only valid in a few use cases. When listening for connections, it means "listen on all IPs". This is a placeholder that the OS handles - it doesn't literally use that IP. Also, it's used as the source address for packets where the system doesn't have an IP yet (eg for DHCP). That's it.
0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network. Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network ([RFC1122], Section
3.2.1.3).
We now summarize the important special cases for Class A, B,
and C IP addresses, using the following notation for an IP
address:
{ <Network-number>, <Host-number> }
or
{ <Network-number>, <Subnet-number>, <Host-number> }
...
(a) { 0, 0 }
This host on this network. MUST NOT be sent, except as
a source address as part of an initialization procedure
by which the host learns its own IP address.
See also Section 3.3.6 for a non-standard use of {0,0}.
(section 3.3.6 just talks about it being a legacy IP for broadcasts - I don't think that even works any more)
Yeah, I just did a quick test in Python to do a tcp connection to "0.0.0.0" and it made a loopback connection, instead of returning an error as I would have expected.
While I agree, it makes connecting to localhost as easy as http://0:8080/ (for port 8080, but omit for port 80).
I worry that changing this will cause more CVEs like the octal IP addresses incident.
Edit: looks like it's only being blocked for outgoing requests from websites, which seems like it'll have a much more reasonable impact.
Edit 2: skimming through these PRs, at least for WebKit, I don't see tests for shorthand IPs like 0 (and no Apple device to test with). What are the chances they missed those..?
it makes connecting to localhost as easy as http://0:8080/ (for port 8080, but omit for port 80).
The thing is that it's not supposed to work, so it's essentially relying on undefined behaviour. Typing [::1]:8080 is nearly as easy.
skimming through these PRs, at least for WebKit, I don't see tests for shorthand IPs like 0 (and no Apple device to test with). What are the chances they missed those..?
I haven't seen the PRs, but IP comparison should really be using the binary form of the IPv4 address (a 32-bit number), not the human-friendly form.