JDK 25 HttpClient SOCKS ProxySelector માર્ગોનો ઉપયોગ કરતું નથી

Java પ્રોક્સી ઑબ્જેક્ટ એક માર્ગનું વર્ણન કરે છે. નેટવર્કિંગ ક્લાયન્ટ હજી પણ નક્કી કરે છે કે તે કયા પ્રકારના માર્ગો વાપરી શકે. જ્યારે ઉપલબ્ધ એન્ડપોઇન્ટ SOCKS બોલે છે અને એપ્લિકેશન java.net.http.HttpClient વાપરે છે ત્યારે આ મહત્ત્વનું છે.

અહીં તપાસાયેલા JDK 25 અમલીકરણમાં, HTTP ક્લાયન્ટનો વિનંતી કોડ સિલેક્ટર પાસેથી HTTP ઉમેદવાર સ્વીકારે છે. SOCKS ઉમેદવાર તેને SOCKS વાટાઘાટ કરવા માટે મજબૂર કરતું નથી; અમલીકરણ પ્રોક્સી વગર આગળ વધી શકે છે. તેથી સફળ પ્રતિસાદ એ પુરાવો નથી કે કસ્ટમ સિલેક્ટરની SOCKS એન્ટ્રી વપરાઈ.

પહેલા પરિવહન પસંદ કરો

URLConnection આધારિત હાલની એપ્લિકેશન માટે, કનેક્શન ખોલતી વખતે પ્રોટોકોલ હેન્ડલરને સમર્થિત સ્પષ્ટ પ્રોક્સી આપી શકાય:

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

મંજૂર જાહેર-લક્ષ્ય પરીક્ષણો માટે, તમારી સેવા અથવા SOCKS પ્રોક્સી સૂચિમાંથી મેળ ખાતું SOCKS એન્ડપોઇન્ટ વાપરો. આ એક અલગ ક્લાયન્ટ API છે, HttpClient.Builder.proxy ની વૈકલ્પિક જોડણી નથી. લક્ષ્ય URL રાખો જેથી HTTPS ઇચ્છિત વેબસાઇટ ઓળખતું રહે.

java.net.http જાળવવું પડે તેવી એપ્લિકેશન તેના બદલે સુસંગત HTTP પ્રોક્સી એન્ડપોઇન્ટ વાપરી શકે, જેમાં આગળનું SOCKS કનેક્શન સંભાળતું મંજૂર એડેપ્ટર પણ સામેલ છે. તે વાસ્તવિક ઘટક અને બીજી ઍક્સેસ સીમા ઉમેરે છે; પોર્ટ 8080 ને 1080 કરવાથી એ અનુવાદ મળતું નથી.

પસંદગી અને અપનાવવું દૃશ્યમાન રાખો

સિલેક્ટરનું પરિણામ અને ક્લાયન્ટ ખરેખર ખોલે તે કનેક્શન બંને નોંધો. પ્રથમ નીતિનું આઉટપુટ વર્ણવે છે; બીજું નક્કી કરે છે કે અમલીકરણે તેને અપનાવ્યું કે નહીં.

તારણોને વપરાતા રનટાઇમ અને પરિવહન સાથે જોડો. એક સોકેટ અમલીકરણ વાપરે તે JVM SOCKS ગુણધર્મો એ વચન નથી કે દરેક HTTP લાઇબ્રેરી તેમને પૂછે છે. જ્યારે માર્ગ ફરજિયાત હોય, ત્યારે દેખીતી રીતે સફળ સીધી વિનંતી સ્વીકારતા પહેલા અસમર્થિત પ્રોક્સી પ્રકાર શોધાવો જોઈએ.