Spring WebClient med Jetty: vanlig HTTP-proxy uten CONNECT

Bruk Springs Jetty-kobling med samsvarende HTTP/1.1-protokoller for klient og proxy når en vanlig videresendt HTTP-forespørsel kreves.

HTTP-proxybehandleren i Reactor Netty etablerer en CONNECT-tunnel selv for et vanlig HTTP-mål. Hvis den tiltenkte proxyen i stedet godtar vanlig HTTP/1.1-videresending, kan Spring WebClient bruke en annen støttet kobling.

For Spring 6.2 med Jetty 12.0.35 sin klient-API og kompatibel Jetty Reactive Streams-integrasjon:

var jetty = new org.eclipse.jetty.client.HttpClient(
    new org.eclipse.jetty.client.transport.HttpClientTransportOverHTTP());
jetty.getProxyConfiguration().addProxy(
    new org.eclipse.jetty.client.HttpProxy("proxy.example", 8080));

var client = WebClient.builder()
    .clientConnector(new JettyClientHttpConnector(jetty))
    .build();

WebClient og JettyClientHttpConnector er Spring-klasser. Håndter oppstart og avslutning av den medfølgende Jetty-klienten gjennom applikasjonens normale livssyklus.

HTTP/1.1-proxyen til Jetty kan videresende en vanlig HTTP/1.1-forespørsel uten tunnel når protokollene for målet og klientproxyen samsvarer. requiresTunnel-policyen bruker CONNECT for sikre mål og for inkompatible protokollbaner.

Dette er ikke en måte å fjerne CONNECT fra en vanlig HTTPS-tunnel. Hold målets scheme riktig.

Bruk addProxy i den angitte Jetty-API-en. getProxies returnerer en liste som ikke kan endres, så den eldre oppskriften getProxies().add(...) er ikke dens nåværende endringsgrensesnitt.

For offentlige HTTP-mål på en tillatt offentlig proxy-rute gir HTTP-proxyoversikten kandidater for vert og port for Jetty-proxyen. Les den faktiske proxyresponsen når du sammenligner koblinger. Autentisering, målpolicy og et utilgjengelig mål forblir atskilt fra valget mellom videresendt HTTP og CONNECT.

Relaterte artikler