Spring WebClient з Jetty: звичайне HTTP-проксіювання без CONNECT

Використовуйте конектор Jetty зі Spring з узгодженими протоколами HTTP/1.1 клієнта й проксі, коли потрібен звичайний переспрямований HTTP-запит.

Обробник HTTP-проксі в Reactor Netty створює тунель CONNECT навіть для звичайного HTTP-призначення. Якщо передбачуваний проксі приймає звичайне переспрямування HTTP/1.1, Spring WebClient може використати інший підтримуваний конектор.

Для Spring 6.2 з клієнтським API Jetty 12.0.35 і сумісною інтеграцією Jetty Reactive Streams:

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 і JettyClientHttpConnector — класи Spring. Керуйте запуском і зупинкою наданого клієнта Jetty через звичайний життєвий цикл застосунку.

HTTP/1.1-проксі Jetty може переспрямувати звичайний HTTP/1.1-запит без тунелю, коли протоколи призначення й клієнтського проксі збігаються. Його політика requiresTunnel використовує CONNECT для захищених призначень і несумісних протокольних шляхів.

Це не спосіб прибрати CONNECT зі звичайного тунелю HTTPS. Зберігайте правильну схему призначення.

Використовуйте addProxy у зазначеному API Jetty. getProxies повертає незмінний список, тому старий рецепт getProxies().add(...) не є поточним інтерфейсом зміни.

Для публічних HTTP-призначень на дозволеному публічному проксі-маршруті список HTTP-проксі надає кандидатів для хоста й порту проксі Jetty. Порівнюючи конектори, читайте фактичну відповідь проксі. Автентифікація, політика призначення й недоступне призначення залишаються окремо від вибору переспрямованого HTTP чи CONNECT.

Схожі статті