HTTP-proksi kasutamine Java HttpClientis

Java 11 või uuema puhul määra kliendiehitajale ProxySelector. Kogu JVM-i proksiomadused jäävad nii puutumata:

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

Asenda dokumentatsiooni otspunkt oma HTTP-proksiga; HTTP-proksiloend pakub katsetamiseks kandidaate. ProxySelector.of võtab sokliaadressi: kasuta hosti ilma http:// eesliiteta ja anna port eraldi. See valib HTTP-proksi, mitte pordinumbri põhjal SOCKSi. Päringu URI jääb tegelikuks sihtkohaks.

HTTPS saab seda HTTP-proksit läbida tunneli kaudu. Sihtkoha kaitset ei ole vaja nõrgendada ning seadistus ei tähenda proksi kuulaja enda TLS-tuge.

Kliendiehitaja ühenduse aegumine rakendub ühenduse loomisel; päringul on oma aegumine. Hoia mõlemad nähtavad, sest päring võib olemasolevat ühendust taaskasutada. Võrgu-, autentimis- või tunnelierind võib tekkida enne mis tahes sihtkoha vastust, kuid tagastatud veastaatus ei pea erindit tekitama.

Taaskasuta klienti sama marsruutimispoliitikaga päringute jaoks, et rakendus saaks kasu selle ühendusehaldusest.