JDK 25 HttpClient ei käytä ProxySelectorin SOCKS-reittejä

Java-välityspalvelinobjekti kuvaa reitin. Verkkoympäristön asiakasohjelma päättää edelleen, minkä tyyppisiä reittejä se voi käyttää. Tällä on merkitystä, kun käytettävissä oleva päätepiste puhuu SOCKSia ja sovellus käyttää java.net.http.HttpClient.

Tässä tarkastellussa JDK 25 -toteutuksessa HTTP-asiakasohjelman pyyntökoodi hyväksyy valitsimelta HTTP-ehdokkaan. SOCKS-ehdokas ei saa sitä suorittamaan SOCKS-neuvottelua; toteutus voi jatkaa ilman välityspalvelinta. Onnistunut vastaus ei siis riitä todisteeksi siitä, että mukautetun valitsimen SOCKS-merkintää käytettiin.

Valitse ensin kuljetus

Olemassa olevalle URLConnection-pohjaiselle sovellukselle voidaan antaa protokollankäsittelijälle tuettu nimenomainen välityspalvelin yhteyttä avattaessa:

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);

Sallituissa julkisten kohteiden testeissä käytä vastaavaa SOCKS-päätepistettä palvelustasi tai SOCKS-välityspalvelinluettelosta. Tämä on eri asiakasrajapinta, ei vaihtoehtoinen kirjoitusasu HttpClient.Builder.proxy:lle. Säilytä kohde-URL, jotta HTTPS tunnistaa edelleen aiotun verkkosivuston.

Sovellus, jonka on säilytettävä java.net.http, voi sen sijaan käyttää yhteensopivaa HTTP-välityspalvelimen päätepistettä, mukaan lukien hyväksytty sovitin, joka hoitaa jatkoyhteyden SOCKSina. Se lisää todellisen komponentin ja vielä yhden käyttörajan; portin 8080 vaihtaminen 1080:aan ei tarjoa tätä käännöstä.

Pidä valinta ja käyttöönotto näkyvinä

Kirjaa sekä valitsimen tulos että yhteys, jonka asiakasohjelma todella avaa. Ensimmäinen kuvaa käytännön tulosteen; toinen osoittaa, ottiko toteutus sen käyttöön.

Kiinnitä johtopäätökset käytössä olevaan ajonaikaiseen ympäristöön ja kuljetukseen. Yhden socket-toteutuksen käyttämät JVM:n SOCKS-ominaisuudet eivät ole lupaus siitä, että jokainen HTTP-kirjasto kysyy niitä. Kun reitti on pakollinen, tukematon välityspalvelintyyppi olisi havaittava ennen näennäisesti onnistuneen suoran pyynnön hyväksymistä.