Java puhverserveri objekt kirjeldab marsruuti. Võrguklient otsustab siiski, millist tüüpi marsruute ta kasutada saab. See on oluline siis, kui saadaolev lõpp-punkt räägib SOCKS-it ja rakendus kasutab java.net.http.HttpClient.

Siin vaadeldavas JDK 25 teostuses võtab HTTP-kliendi päringukood selektorilt vastu HTTP-kandidaadi. SOCKS-kandidaat ei pane seda SOCKS-läbirääkimisi tegema; teostus võib jätkata ilma puhverserverita. Seega ei ole õnnestunud vastus piisav tõestus, et kohandatud selektori SOCKS-kirje oli kasutusel.

Vali esmalt transport

Olemasoleva URLConnection-põhise rakenduse puhul saab protokollikäsitlejale ühenduse avamisel anda toetatud selgesõnalise puhverserveri:

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

Lubatud avalike sihtmärkide testide jaoks kasutage sobivat SOCKS-lõpp-punkti oma teenusest või SOCKS-puhverserverite loendist. See on teine kliendi API, mitte HttpClient.Builder.proxy alternatiivne kirjaviis. Säilitage siht-URL, et HTTPS tuvastaks jätkuvalt kavandatud veebisaidi.

Rakendus, mis peab säilitama java.net.http, võib selle asemel kasutada ühilduvat HTTP-puhverserveri lõpp-punkti, sealhulgas kinnitatud adapterit, mis tegeleb edasise SOCKS-ühendusega. See lisab tõelise komponendi ja veel ühe juurdepääsupiiri; pordi 8080 muutmine 1080-ks seda tõlget ei anna.

Hoia valik ja omaksvõtt nähtavad

Registreerige nii selektori tulemus kui ka ühendus, mille klient tegelikult avab. Esimene kirjeldab poliitika väljundit; teine teeb kindlaks, kas teostus selle omaks võttis.

Siduge järeldused kasutatava käituskeskkonna ja transpordiga. Ühe socketi teostuse kasutatavad JVM-i SOCKS-omadused ei ole lubadus, et iga HTTP-teek neid küsib. Kui marsruut on kohustuslik, tuleks toetamata puhverserveri tüüp tuvastada enne näiliselt õnnestunud otsese päringu vastuvõtmist.

Seotud artiklid