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 लाइब्रेरी उनसे परामर्श करती है। जब मार्ग अनिवार्य हो, तो स्पष्ट रूप से सफल प्रत्यक्ष अनुरोध स्वीकार करने से पहले असमर्थित प्रॉक्सी प्रकार का पता लगाया जाना चाहिए।