RFR: 8346017: Socket.connect specified to throw UHE for unresolved address is problematic for SOCKS V5 proxy [v2]

Daniel Fuchs dfuchs at openjdk.org
Fri Dec 13 16:35:41 UTC 2024


On Thu, 12 Dec 2024 18:54:16 GMT, Volkan Yazıcı <duke at openjdk.org> wrote:

>> [JDK-8343791](https://bugs.openjdk.org/browse/JDK-8343791) modified `Socket::connect` to throw `UHE` on unresolved addresses – merged in #22160. As reported in [JDK-8346017](https://bugs.openjdk.org/browse/JDK-8346017), this renders `connect()` unusable when there is a (SOCKS) proxy in play, where calling `connect()` using unresolved addresses is a valid operation. This PR
>> 
>> 1. Reverts the earlier `Socket::connect` change
>> 2. Updates tests accordingly
>> 3. Enhances tests with proxied socket inputs
>> 
>> These changes require CSR and RN tickets. I will implement them once we agree on a solution here.
>
> Volkan Yazıcı has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix `Socket::connect` javadoc

test/jdk/java/net/Socket/ConnectFailTest.java line 85:

> 83:     @BeforeAll
> 84:     static void initSocksServer() throws IOException {
> 85:         SOCKS_SERVER = new SocksServer(0);

We should use the constructor that takes an InetAddress and bind to the loopback.

SocksServer(InetAddress addr, int port, boolean useV4)

test/jdk/java/net/Socket/ConnectFailTest.java line 118:

> 116:     void testBoundSocket(SocketArg socketArg) throws IOException {
> 117:         try (Socket socket = socketArg.socket) {
> 118:             socket.bind(new InetSocketAddress(0));

If the server is bound to the loopback we could bind to the loopback here too. That should reduce potential instabilities.

test/jdk/java/net/Socket/ConnectFailTest.java line 167:

> 165:     void testBoundSocketWithUnresolvedAddress(SocketArg socketArg) throws IOException {
> 166:         try (Socket socket = socketArg.socket) {
> 167:             socket.bind(new InetSocketAddress(0));

If the server is bound to the loopback we could bind to the loopback here too. That should reduce potential instabilities.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22719#discussion_r1883722965
PR Review Comment: https://git.openjdk.org/jdk/pull/22719#discussion_r1883725958
PR Review Comment: https://git.openjdk.org/jdk/pull/22719#discussion_r1883725285


More information about the net-dev mailing list