У застосунку на Apache HttpClient 4 HTTPS-призначення не означає, що кожне з'єднання починається з TLS. До звичайного HTTP-проксі доходять незашифрованим з'єднанням, перш ніж CONNECT відкриє тунель і TLS буде накладено в бік призначення.

Якщо власний менеджер з'єднань реєструє лише https, перший крок через проксі може завершитися помилкою UnsupportedSchemeException: http protocol is not supported.

Для API 4.5 під час створення цього менеджера включіть обидві фабрики:

var registry = RegistryBuilder.<ConnectionSocketFactory>create()
    .register("http", PlainConnectionSocketFactory.getSocketFactory())
    .register("https", tlsFactory)
    .build();

var manager = new PoolingHttpClientConnectionManager(registry);
var client = HttpClients.custom()
    .setConnectionManager(manager)
    .setProxy(new HttpHost("proxy.example.net", 8080, "http"))
    .build();

tlsFactory — це наявна SSLConnectionSocketFactory застосунку з передбаченою перевіркою довіри та імені хоста. Показані типи належать пакетам org.apache.http Apache 4. Фрагмент припускає виведення типів локальних змінних Java; старіший код Java може використовувати явні типи.

Приєднайте виправлений менеджер до клієнта, який фактично використовується для запиту. Для дозволеного публічного HTTPS-запиту без автентифікації проксі HTTP-запис зі списку HTTP-проксі може заповнити адресу проксі в HttpHost. Налаштування іншого builder не оновлює вже створений клієнт.

Перевірте також належність builder: HttpClientBuilder документує, що явно наданий менеджер з'єднань може перекрити його окремі входи конфігурації SSL. Розміщуйте потрібні фабрики в реєстрі менеджера, а не припускайте, що пізніший виклик setSSLContext замінить його внутрішній вміст.

Ця діагностика стосується локального реєстру схем. Запит автентифікації проксі або відхилене призначення — пізніший, інший результат. Зберігайте обидві реєстрації фабрик, поки досліджуєте ці відповіді.

Схожі статті