‏JDK 25 HttpClient אינו משתמש בנתיבי SOCKS של ProxySelector

‏אובייקט proxy של Java מתאר נתיב. לקוח הרשת עדיין מחליט באילו סוגי נתיב הוא יכול להשתמש. זה חשוב כשנקודת הקצה הזמינה מדברת SOCKS והאפליקציה משתמשת ב־java.net.http.HttpClient.

במימוש JDK 25 הנבדק כאן, קוד הבקשה של לקוח ה-HTTP מקבל מועמד HTTP מהבורר. מועמד SOCKS אינו גורם לו לבצע משא ומתן SOCKS; המימוש יכול להמשיך בלי proxy. לכן תגובה מוצלחת אינה הוכחה מספקת לכך שהשתמשו ברשומת ה-SOCKS של בורר מותאם.

בחרו קודם את התעבורה

באפליקציה קיימת המבוססת על URLConnection, אפשר לתת למטפל הפרוטוקול 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);

לבדיקות מותרות של יעדים ציבוריים, השתמשו בנקודת קצה SOCKS מתאימה מהשירות שלכם או מרשימת ה-proxy של SOCKS. זהו API לקוח אחר, לא איות חלופי של HttpClient.Builder.proxy. שמרו על כתובת ה-URL של היעד כדי ש-HTTPS ימשיך לזהות את האתר המיועד.

אפליקציה שחייבת לשמור על java.net.http יכולה להשתמש במקום זאת בנקודת קצה תואמת של proxy HTTP, כולל מתאם מאושר שמטפל בחיבור ה-SOCKS שלאחר מכן. זה מוסיף רכיב אמיתי ועוד גבול גישה; שינוי הפורט 8080 ל-1080 אינו מספק את התרגום הזה.

שמרו על בחירה ואימוץ גלויים

תעדו גם את תוצאת הבורר וגם את החיבור שהלקוח פותח בפועל. הראשון מתאר פלט מדיניות; השני קובע אם המימוש אימץ אותו.

קשרו מסקנות לסביבת הריצה ולתעבורה שבשימוש. מאפייני SOCKS של JVM שמימוש socket אחד משתמש בהם אינם הבטחה שכל ספריית HTTP מתייעצת איתם. כאשר הנתיב חובה, יש לזהות סוג proxy לא נתמך לפני קבלת בקשה ישירה שנראית מוצלחת.