שימוש בפרוקסי HTTP עם Java HttpClient

ב-Java 11 ומעלה, הגדירו ProxySelector על בונה הלקוח. כך מאפייני הפרוקסי של כל ה-JVM נשארים ללא שינוי:

import java.net.InetSocketAddress;
import java.net.ProxySelector;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;

public class ProxyExample {
    public static void main(String[] args) throws Exception {
        HttpClient client = HttpClient.newBuilder()
            .proxy(ProxySelector.of(
                new InetSocketAddress("203.0.113.10", 8080)))
            .connectTimeout(Duration.ofSeconds(5))
            .build();

        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create("https://example.com/"))
            .timeout(Duration.ofSeconds(15))
            .GET()
            .build();

        HttpResponse<String> response = client.send(
            request, HttpResponse.BodyHandlers.ofString());
        System.out.println(response.statusCode());
        System.out.println(response.body());
    }
}

החליפו את נקודת ההדגמה בפרוקסי HTTP שלכם; רשימת הפרוקסי HTTP מספקת מועמדים לבדיקה. ProxySelector.of מקבל כתובת שקע: השתמשו במארח ללא התחילית http:// וספקו את הפורט בנפרד. הוא בוחר פרוקסי HTTP, לא SOCKS לפי מספר הפורט. URI הבקשה נשאר היעד האמיתי.

HTTPS יכול לעבור דרך פרוקסי HTTP הזה באמצעות מנהרה. אין צורך להוריד את רמת ההגנה של היעד, וההגדרה אינה מעידה שהמאזין של הפרוקסי עצמו תומך ב-TLS.

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

השתמשו שוב בלקוח לבקשות עם אותה מדיניות ניתוב כדי שהיישום ייהנה מניהול החיבורים שלו.