JDK 25 HttpClient neizmanto ProxySelector SOCKS maršrutus

Java proxy objekts apraksta maršrutu. Tīkla klients joprojām izlemj, kādus maršruta veidus tas var izmantot. Tas ir svarīgi, kad pieejamais galapunkts runā SOCKS un programma izmanto java.net.http.HttpClient.

Šeit apskatītajā JDK 25 ieviešanā HTTP klienta pieprasījuma kods pieņem HTTP kandidātu no selektora. SOCKS kandidāts tam neliek veikt SOCKS sarunas; ieviešana var turpināt bez proxy. Tāpēc veiksmīga atbilde nav pietiekams pierādījums, ka tika izmantots pielāgota selektora SOCKS ieraksts.

Vispirms izvēlieties transportu

Esošai URLConnection balstītai programmai, atverot savienojumu, protokola apdarinātājam var nodot atbalstītu skaidru proxy:

Proxy route = new Proxy(Proxy.Type.SOCKS,
    new InetSocketAddress("proxy.example", 1080));
URLConnection connection = URI.create("https://service.example/")
    .toURL().openConnection(route);
connection.setConnectTimeout(5000);
connection.setReadTimeout(15000);

Atļautiem publisku mērķu testiem izmantojiet atbilstošu SOCKS galapunktu no sava pakalpojuma vai no SOCKS proxy saraksta. Šis ir cits klienta API, nevis alternatīvs HttpClient.Builder.proxy rakstījums. Saglabājiet galamērķa URL, lai HTTPS turpinātu identificēt paredzēto vietni.

Programma, kurai jāsaglabā java.net.http, tā vietā var izmantot saderīgu HTTP proxy galapunktu, tostarp apstiprinātu adapteri, kas apstrādā turpmāko SOCKS savienojumu. Tas pievieno reālu komponenti un vēl vienu piekļuves robežu; porta 8080 maiņa uz 1080 šo tulkojumu nesniedz.

Turiet izvēli un pārņemšanu redzamu

Reģistrējiet gan selektora rezultātu, gan savienojumu, ko klients faktiski atver. Pirmais apraksta politikas izvadi; otrais nosaka, vai ieviešana to pārņēma.

Saistiet secinājumus ar izmantoto izpildlaiku un transportu. JVM SOCKS īpašības, ko izmanto viena ligzdas ieviešana, nav solījums, ka katra HTTP bibliotēka tās konsultē. Ja maršruts ir obligāts, neatbalstīts proxy tips ir jāatklāj pirms šķietami veiksmīga tieša pieprasījuma pieņemšanas.