On Fri, 16 Jul 2021 09:16:23 GMT, Jonathan Dowland <jdowl...@openjdk.org> wrote:
> The tests `test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java` uses > the IP address "1.1.1.1" as a value. I think at the time the address was > picked, the assumption was the address was not valid / not routable. Since > April 2018 the address is part of CloudFlare's "Free" DNS product: > <https://en.wikipedia.org/wiki/1.1.1.1>. (this test was originally written in > 2016, before the service was launched) > > I've verified using local packet captures that running the test does result > in IP traffic being sent to 1.1.1.1. (Several other tests in JDK use 1.1.1.1 > as a placeholder IP. I've checked them all and none of the others connect out > to the IP like this one) > > This PR substitutes that IP address value (and two others) for ones from a > reserved IP range (240.0.0.0/4 according to RFC 6761) which will not result > in runners of the test suit inadvertently sending IP packets to the > CloudFlare service. > > This could be invalidated again if that address range is allocated at some > point in the future. A more future-proof fix would be to bind to random ports > on localhost for each dummy proxy (as done for the target HTTP server in the > test already). I can do that if preferred. > > <https://bugs.openjdk.java.net/browse/JDK-8270553> I had to read up if this would work, and I am somewhat convinced it would. [IANA Database](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml ) mentions these addresses are Reserved-by-Protocol, and refers to [RFC 1112, Section 4](https://www.rfc-editor.org/rfc/rfc1112.html) which mentions these are reserved for future addressing modes. But this rabbit hole excursion makes me think it would be better to just use the local loopback in these tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/4806
